Asynchronous tracking method of vehicle remote control link and electronic equipment

Abstract

The invention provides an asynchronous tracking method for a vehicle remote control link, and belongs to the technical field of Internet of Vehicles, and the method comprises the steps: a cloud service platform side defines a plurality of key tracking nodes, and the key tracking nodes cover the life cycle stages of issuing, transmitting, responding and exception handling of a remote control instruction; standardized node tracking data is generated at each key tracking node, and the node tracking data at least comprises a vehicle identification code used for uniquely identifying a vehicle and a message serial number used for associating a single operation full link; releasing the node tracking data to a specified theme of a message queue system in an asynchronous calling mode to ensure that the processing of the remote control main service is not blocked by log recording operation; and monitoring the message queue theme through an independent log consumption service, and persisting the obtained node tracking data to a non-relational database to form a complete link tracking record for fault diagnosis.

Description

Technical Field

[0001] This invention relates to the field of vehicle networking technology, and in particular to an asynchronous tracking method and electronic device for a vehicle remote control link. Background Technology

[0002] With the widespread adoption of intelligent connected vehicles, remote control (such as remotely opening and closing doors, windows, and air conditioning) has become a core function frequently used by users. The remote control chain involves multiple heterogeneous systems, including mobile applications (Apps), vehicle-to-everything (TSP) cloud platforms, connectivity platforms, in-vehicle T-Boxes, and vehicle controllers, resulting in a long and complex chain. When remote control operations fail or are delayed, maintenance personnel face significant troubleshooting challenges: traditionally, they need to log into various cloud microservices and vehicle devices separately to query logs, a cumbersome and inefficient process that makes it difficult to correlate scattered logs to reconstruct the complete command propagation path.

[0003] While existing technologies include logging at critical nodes, these are mostly synchronous operations that can block main business logic and easily lead to service performance bottlenecks or even cascading failures in high-concurrency scenarios. Furthermore, inconsistent log formats and a lack of effective associated IDs hinder rapid end-to-end problem localization. Therefore, there is an urgent need for a low-intrusion, high-performance, end-to-end visualized remote control and tracing solution. Summary of the Invention

[0004] In view of the technical defects and drawbacks existing in the prior art, embodiments of the present invention provide an asynchronous tracking method and electronic device for a vehicle remote control link to overcome the above problems or at least partially solve the above problems, the specific solution of which is as follows;

[0005] As a first aspect of the present invention, an asynchronous tracking method for a vehicle remote control link is provided. The method is based on an architecture that separates business logic from log logic, and aims to monitor the status and path of vehicle remote control commands throughout the entire lifecycle of vehicle-cloud interaction. The method includes the following steps:

[0006] The cloud service platform defines multiple key tracking nodes, which cover the lifecycle stages of remote control command issuance, transmission, response, and exception handling.

[0007] At each of the key tracking nodes, standardized node tracking data is generated, which includes at least a vehicle identification code for uniquely identifying the vehicle and a message serial number for associating the entire chain of a single operation.

[0008] By using asynchronous calls, the node tracking data is published to a designated topic in the message queue system, ensuring that the processing of the main remote control business is not blocked by log recording operations;

[0009] By listening to the message queue topic through an independent log consumption service, the acquired node tracing data is persisted to a non-relational database to form a complete link tracing record for fault diagnosis.

[0010] Optionally, the key tracking node includes at least a sending sequence node for monitoring the forward propagation process of remote control commands, and a response sequence node for monitoring the reverse feedback process of command execution results.

[0011] The issued sequence nodes and the response sequence nodes together constitute the basic timing framework for tracking the entire lifecycle of the vehicle-cloud interaction.

[0012] Optionally, the sequence nodes include at least a first node and a third node;

[0013] The first node is located when the vehicle network service platform sends a remote control command to the connection platform after completing the command verification and encapsulation.

[0014] The third node is located when the connection platform converts the remote control command into a vehicle-readable message and sends it to the vehicle T-Box;

[0015] The first node and the third node, according to the instruction issuance sequence, form the critical path of the forward propagation process.

[0016] Optionally, the method further includes: defining an optional wake-up sequence before the start of the delivery sequence node;

[0017] When the vehicle networking service platform determines that the target vehicle's in-vehicle T-Box is offline, the wake-up sequence is triggered;

[0018] In this wake-up sequence, when the vehicle network service platform generates and issues the T-Box wake-up command, wake-up tracking data containing the vehicle identification code and wake-up serial number is generated and asynchronously published to the message queue system as independent node tracking data.

[0019] Optionally, the response sequence nodes include at least a second node, a fourth node, and a fifth node;

[0020] The second node is located when the connection platform receives the final execution result of the instruction returned by the vehicle-mounted T-Box; the fourth node is located when the connection platform receives the confirmation response of the vehicle-mounted T-Box to the instruction, and it is earlier than the second node in terms of timing.

[0021] The fifth node is located when the vehicle network service platform receives the final execution result of the instruction forwarded by the connection platform, and it is later than the second node in time sequence;

[0022] The fourth, second, and fifth nodes, responding in the order of instructions, together constitute the complete path of the reverse feedback process, with the fifth node serving as the endpoint of the end-to-end tracking for a single remote control operation. At this fifth node, the vehicle network service platform generates final result tracking data and asynchronously publishes this data to the message queue system or directly writes it to its business database to complete the end-to-end tracking loop for a single remote control operation.

[0023] Optionally, the asynchronous call is implemented through a decoupled microservice architecture that isolates the business processing service that generates node tracing data from the log reporting service that is responsible for log communication in terms of processes;

[0024] When a critical tracing node is triggered, the business processing service calls the application interface of the log reporting service through cross-process communication and transmits the standardized node tracing data. The log reporting service is configured to immediately publish the data to the message queue system in a non-blocking asynchronous manner after receiving the data, thereby ensuring that the execution flow of the business processing service depends only on the successful application interface call, and not on whether the log data has been transmitted and persisted over the network.

[0025] Optionally, the persistence process includes a data normalization mapping rule;

[0026] The log consumption service is configured to map JSON-formatted node tracking data in the message queue into a document model suitable for a non-relational database according to predefined rules.

[0027] The document model predefines several core fields, including at least:

[0028] a) Vehicle identification number (VIN) serves as the primary partition key for data retrieval;

[0029] b) The message serial number serves as the association key for tracking data across all nodes under the same remote control operation;

[0030] c) Node timestamps, used to determine the timing of nodes within a single operation;

[0031] d) Node type identifier, used to distinguish the logical role of a node in the business chain;

[0032] e) Data payload, used to store node-specific business information.

[0033] By using mapping rules, heterogeneous node data is transformed into documents with a unified structure and written into a non-relational database to achieve unified and efficient storage and querying of heterogeneous node tracking data.

[0034] Optionally, it also includes: providing a fault diagnosis service based on the complete link tracing record;

[0035] The fault diagnosis service receives a diagnosis request through a query interface, and the diagnosis request includes at least the target vehicle identification code and the query time range.

[0036] The fault diagnosis service is configured to perform the following operations:

[0037] a) Based on the VIN and time range, retrieve all relevant documents from the non-relational database;

[0038] b) Based on the message serial number in the document model, aggregate all node tracking documents belonging to the same remote control operation to generate a complete link tracking record;

[0039] c) For the aggregated link tracing records, sort them in time sequence according to the node timestamps in the document model, and parse the node type identifier and data payload;

[0040] d) Visualize the parsed results to present the complete propagation path of remote control commands, the status of each node, and the time consumption in a graphical interface, thereby enabling rapid fault location and performance analysis.

[0041] Optionally, the key tracking node also includes an abnormal status node for monitoring service anomalies in the vehicle-cloud interaction link;

[0042] When the business logic execution of any participant in the link is interrupted or returns to failure due to verification failure, communication timeout, or instruction execution error, an abnormal state node is triggered.

[0043] An abnormal node tracking data is generated at this node, which includes not only the vehicle identification number and message serial number, but also error code, abnormal description information and service identifier of the abnormal occurrence point.

[0044] The abnormal node tracking data is published and stored in an asynchronous manner, and aggregated together with the successful path node data of the same operation to form a link tracking record containing complete success and failure information, providing a direct basis for judging the cause of the fault for the fault diagnosis service.

[0045] As a second aspect of the present invention, an electronic device is provided, comprising:

[0046] One or more processors;

[0047] Memory, used to store one or more programs;

[0048] When the one or more programs are executed by the one or more processors, the one or more processors implement the methods described above.

[0049] The present invention has the following beneficial effects:

[0050] This invention, through an architecture that separates business logic from logging logic and asynchronous calls, eliminates the performance impact of logging on the main remote control business chain, ensuring high real-time performance of remote control operations. Even under high concurrency or temporary congestion of the logging system, core business operations can be executed without interference, meeting the stringent response speed requirements of vehicle networking applications. By defining key nodes covering the entire lifecycle of "issuance, transmission, response, and exception handling," the complete flow path of a single remote control command between the cloud and the vehicle becomes completely transparent, providing a complete data foundation for rapid and accurate problem localization. This overcomes the previous limitations of relying on fragmented logs and difficulty in reproducing the entire process during troubleshooting. The solution specifies a complete standardized process from data generation (standardized node tracking data), transmission (message queues), to storage (non-relational databases), ensuring high efficiency in data processing and providing excellent scalability. New tracking nodes can be easily added or data formats adjusted without refactoring the overall architecture. Attached Figure Description

[0051] Figure 1 A flowchart illustrating an asynchronous tracking method for a vehicle remote control link provided in an embodiment of the present invention;

[0052] Figure 2 This is a flowchart illustrating the wake-up sequence of the method provided in the embodiments of the present invention;

[0053] Figure 3 This is a flowchart illustrating the two main stages of forward propagation (sequence delivery) and reverse feedback (response sequence) provided in this embodiment of the invention.

[0054] Figure 4 This is a flowchart illustrating an abnormal state node in a vehicle-to-cloud interaction link for monitoring service anomalies, as provided in an embodiment of the present invention.

[0055] Figure 5 This is a structural block diagram of an electronic device provided in an embodiment of the present invention. Detailed Implementation

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

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

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

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

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

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

[0062] To address at least one of the technical problems existing in the aforementioned related technologies, the present invention provides an asynchronous tracking method for a vehicle remote control link. Figure 1 This is a flowchart illustrating an asynchronous tracking method for a vehicle remote control link provided by an embodiment of the present invention. The method is based on an architecture that separates business logic from log logic, and aims to monitor the status and path of vehicle remote control commands throughout the entire lifecycle of vehicle-cloud interaction. The method includes the following steps:

[0063] S1: The cloud service platform defines multiple key tracking nodes, which cover the lifecycle stages of issuing, transmitting, responding to, and handling exceptions of remote control commands;

[0064] S2: For each of the key tracking nodes, generate standardized node tracking data, which includes at least a vehicle identification code for uniquely identifying the vehicle and a message serial number for associating the entire chain of a single operation.

[0065] S3: Publish the node tracking data to a designated topic in the message queue system via asynchronous calls to ensure that the processing of the main remote control business is not blocked by log recording operations;

[0066] S4: Listen to the message queue topic through an independent log consumption service, persist the acquired node tracing data to a non-relational database, and form a complete link tracing record for fault diagnosis.

[0067] In the above embodiments, the "architecture that separates business logic from log logic" and "asynchronous calls" cut off the performance impact of log recording on the main remote control business link, ensuring high real-time performance of remote control operations. Even under high concurrency or temporary congestion of the log system, core business can be executed without interference, meeting the stringent response speed requirements of vehicle networking applications. By defining key nodes covering the entire lifecycle of "issuance, transmission, response, and exception handling," the complete flow path of a single remote control command between the cloud and the vehicle becomes completely transparent, providing a complete data foundation for rapid and accurate problem localization. This changes the previous predicament of relying on scattered logs and difficulty in reproducing the link during fault diagnosis. The solution specifies a complete standardized process from data generation (standardized node tracking data), transmission (message queue) to storage (non-relational database), ensuring high efficiency in data processing and giving the system good scalability. New tracking nodes can be easily added or data formats adjusted without reconstructing the overall architecture.

[0068] In some embodiments, the key tracking nodes defined in step S1 include at least a sending sequence node for monitoring the forward propagation process of remote control commands and a response sequence node for monitoring the reverse feedback process of command execution results.

[0069] The issued sequence nodes and the response sequence nodes together constitute the basic timing framework for tracking the entire lifecycle of the vehicle-cloud interaction.

[0070] In the above embodiments, the complex vehicle-to-cloud interaction lifecycle is distilled into two core and intuitive monitoring sequences: "forward propagation" and "backward feedback." This allows operations and maintenance personnel to quickly understand the monitoring logic, simplifying a complex interaction into two main lines of instructions: "going" and "returning," thus reducing the complexity of monitoring and troubleshooting. The constructed "basic timing framework" is fundamental for subsequent link latency analysis and latency problem localization. It provides a structured basis for comparing timestamps of different nodes and identifying network latency or service processing bottlenecks, serving as a key prerequisite for performance analysis.

[0071] In some embodiments, the sequence nodes include at least a first node and a third node;

[0072] The first node is located when the vehicle network service platform sends a remote control command to the connection platform after completing the command verification and encapsulation.

[0073] The third node is located when the connection platform converts the remote control command into a vehicle-readable message and sends it to the vehicle T-Box;

[0074] The first node and the third node, according to the instruction issuance sequence, form the critical path of the forward propagation process.

[0075] In the above embodiments, by monitoring the two core stages of "the vehicle network service platform issuing instructions" (first node) and "the connection platform converting and sending instructions to the T-Box" (third node), it is possible to clearly distinguish whether the problem is caused by slow processing of cloud-based business services or by conversion or sending delays in the cloud communication gateway (connection platform). This provides direct data support for optimizing the performance of cloud microservices. These two nodes cover the final steps before instructions are correctly processed and accurately sent in the cloud. Monitoring them effectively confirms whether the instructions have successfully left the cloud and reached the vehicle, providing the first crucial dividing point for determining whether the problem originates in the cloud, the network, or the vehicle.

[0076] In some embodiments, the method further includes: defining an optional wake-up sequence before the start of the delivery sequence node, such as... Figure 2 As shown;

[0077] When the vehicle networking service platform determines that the target vehicle's in-vehicle T-Box is offline, the wake-up sequence is triggered;

[0078] In this wake-up sequence, when the vehicle network service platform generates and issues the T-Box wake-up command, wake-up tracking data containing the vehicle identification code and wake-up serial number is generated and asynchronously published to the message queue system as independent node tracking data.

[0079] In the above embodiments, monitoring the T-Box wake-up process separately allows maintenance personnel to clearly understand the success rate and time taken for the vehicle to go from offline to online. By recording the VIN and serial number of the wake-up request, a possible remote control delay or failure can be clearly linked to the preceding wake-up operation. If remote control fails, it can be quickly determined whether it is caused by a wake-up timeout or failure, avoiding the confusion of faults caused by different reasons and enabling more refined root cause analysis.

[0080] In some embodiments, the response sequence nodes include at least a second node, a fourth node, and a fifth node;

[0081] The second node is located when the connection platform receives the final execution result of the instruction returned by the vehicle-mounted T-Box; the fourth node is located when the connection platform receives the confirmation response of the vehicle-mounted T-Box to the instruction, and it is earlier than the second node in terms of timing.

[0082] The fifth node is located when the vehicle network service platform receives the final execution result of the instruction forwarded by the connection platform, and it is later than the second node in time sequence;

[0083] The fourth, second, and fifth nodes, in accordance with the command response sequence, together constitute the complete path of the reverse feedback process, with the fifth node serving as the end point of the full-link tracking for a single remote control operation.

[0084] At this fifth node, the vehicle network service platform generates final result tracking data and asynchronously publishes this data to the message queue system or directly writes it into its business database to complete the full-link tracking closed loop for a single remote control operation.

[0085] In the above embodiments, by monitoring "T-Box confirmation of receipt" (fourth node) and "T-Box return of final result" (second node), the execution time of the instruction within the vehicle can be accurately calculated. This provides crucial data for distinguishing between network transmission latency and slow execution by the vehicle controller itself. This solution ensures that the entire closed loop from issuing the instruction from the cloud to receiving the final confirmation from the vehicle is traceable. It can clearly verify whether the instruction was 100% delivered to the vehicle (fourth node) and whether the final execution result from the vehicle was 100% reported back to the cloud (second and fifth nodes), effectively solving the two core questions of "whether the instruction was executed?" and "whether the result was returned?", achieving true end-to-end observability. The fifth node (the vehicle network service platform receiving the final result) serves as the endpoint of the full-link tracing, marking the formal completion of a remote control service in the cloud. It links the control request initiated by the cloud with the final received service result, forming a complete and tamper-proof data evidence chain from the initiation point to the end point.

[0086] like Figure 3 As shown, it illustrates the two main stages of remote control command propagation (the sequence of commands sent) and feedback (the sequence of commands received), as well as the position and logical order of five key nodes within these stages.

[0087] Instruction forward propagation sequence: Instruction issuance sequence:

[0088] First step: The vehicle-to-everything (V2X) service platform issues instructions;

[0089] Timing: After the vehicle-to-everything (V2X) service platform verifies and encapsulates the instructions, but before sending them to the connection platform;

[0090] Recorder: Log reporting service on the vehicle networking service platform side;

[0091] Key information: instruction content, source, vehicle identification number, and serial number.

[0092] Third node: Connect the platform to send to the T-Box:

[0093] Timing: After the connection platform converts the command into a message recognizable by the T-Box, but before sending it;

[0094] Recorder: The log reporting service on the connection platform;

[0095] Key information: converted protocol type, service code, vehicle identification number, and serial number.

[0096] Instruction feedback sequence: Response sequence:

[0097] Fourth node: T-Box confirms receipt:

[0098] Timing: After the connection platform receives and decodes the instruction confirmation message returned by the T-Box;

[0099] Recorder: The log reporting service on the connection platform;

[0100] Key information: Reception status, vehicle identification number, serial number.

[0101] Second node: T-Box returns the final result:

[0102] Timing: After the connection platform receives and decodes the final execution result message returned by the T-Box;

[0103] Recorder: The log reporting service on the connection platform;

[0104] Key information: Execution result (success / failure), error code, vehicle identification number, and serial number.

[0105] Fifth step: The vehicle-to-everything (V2X) service platform receives the final result.

[0106] Timing: After the vehicle-to-everything (V2X) service platform receives the final execution result forwarded by the connection platform;

[0107] Recorder: Log reporting service on the vehicle networking service platform side;

[0108] Key information: final business status, vehicle identification number, and serial number.

[0109] Maintenance personnel can use this fault diagram to quickly determine which stage of the fault occurred, for example:

[0110] If there is no third node after the second node, it means that the instruction was not successfully delivered to the vehicle, and the problem lies in the cloud or the network.

[0111] If there is a third node but no fourth node, it means that the T-Box failed to execute or report the instruction correctly after receiving it, and the problem lies with the vehicle-side T-Box.

[0112] If the fourth node fails, you can directly check its recorded error code to pinpoint which controller is experiencing what kind of problem.

[0113] In some embodiments, the asynchronous call in step S3 is implemented through a decoupled microservice architecture that isolates the business processing service that generates node tracing data from the log reporting service that is responsible for log communication in terms of processes.

[0114] When a critical tracing node is triggered, the business processing service calls the application interface of the log reporting service through cross-process communication and transmits the standardized node tracing data. The log reporting service is configured to immediately publish the data to the message queue system in a non-blocking asynchronous manner after receiving the data, thereby ensuring that the execution flow of the business processing service depends only on the successful application interface call, and not on whether the log data has been transmitted and persisted over the network.

[0115] In the above embodiments, by using a "decoupled microservice architecture" and "process isolation", the business service and the log service are completely separated in the runtime environment, ensuring that faults such as memory leaks, high CPU usage or crashes of the log service will not affect the stable operation of the business service, and providing the highest level of fault isolation.

[0116] The stipulation that business services "only depend on the success of application interface calls" means that for business code, logging is equivalent to a local function call, and its success criterion is only whether the log request is successfully sent, rather than whether it is successfully stored. This simplifies error handling in business logic, reduces code complexity, and improves development efficiency.

[0117] Microservice architecture allows log reporting services to be deployed, upgraded, and scaled up independently. When log processing capabilities need to be improved, the log service can be horizontally scaled without modifying or restarting the core business processing services, which greatly improves the overall maintainability and elasticity of the system.

[0118] In some embodiments, the persistence process in step S4 includes a data normalization mapping rule;

[0119] The log consumption service is configured to map JSON-formatted node tracking data in the message queue into a document model suitable for a non-relational database according to predefined rules.

[0120] The document model predefines several core fields, including at least:

[0121] a) Vehicle identification number (VIN) serves as the primary partition key for data retrieval;

[0122] b) The message serial number serves as the association key for tracking data across all nodes under the same remote control operation;

[0123] c) Node timestamps, used to determine the timing of nodes within a single operation;

[0124] d) Node type identifier, used to distinguish the logical role of a node in the business chain;

[0125] e) Data payload, used to store node-specific business information.

[0126] By using mapping rules, heterogeneous node data is transformed into documents with a unified structure and written into a non-relational database to achieve unified and efficient storage and querying of heterogeneous node tracking data.

[0127] In the above embodiments, heterogeneous log data from different nodes and services are forcibly converted into a unified document model through "data standardization mapping rules," solving the common problems of inconsistent log formats and difficulty in correlation analysis in microservice architectures, and laying the foundation for building an enterprise-level unified log platform. Through functional field design (such as using VIN as the "primary partition key"), the data storage structure directly serves the most important query scenario (query by vehicle). This design can make full use of the index and partition characteristics of the database to achieve millisecond-level retrieval under massive data, greatly improving the user experience and operational efficiency of the backend management system. The "message serial number" is explicitly defined as the "association key," which pre-determines the data association method at the data model level, so that the link aggregation operation is no longer a complex post-calculation, but becomes an efficient query based on the database index, ensuring the feasibility and high performance of the full-link tracing function from the root.

[0128] In some embodiments, a step S5 is further included: providing a fault diagnosis service based on the complete link tracing record;

[0129] The fault diagnosis service receives a diagnosis request through a query interface, and the diagnosis request includes at least the target vehicle identification code and the query time range.

[0130] The fault diagnosis service is configured to perform the following operations:

[0131] a) Based on the VIN and time range, retrieve all relevant documents from the non-relational database;

[0132] b) Based on the message serial number in the document model, aggregate all node tracking documents belonging to the same remote control operation to generate a complete link tracking record;

[0133] c) For the aggregated link tracing records, sort them in time sequence according to the node timestamps in the document model, and parse the node type identifier and data payload;

[0134] d) Visualize the parsed results to present the complete propagation path of remote control commands, the status of each node, and the time consumption in a graphical interface, thereby enabling rapid fault location and performance analysis.

[0135] In the above embodiments, the fault diagnosis service frees maintenance personnel from the tedious task of manually grep log files. Through automated event aggregation, time-series sorting, and visualization, it clearly displays the complete path, time, and status of a remote control command, enabling maintenance personnel to form a preliminary judgment on the fault within one second.

[0136] Supporting end-to-end performance analysis, this service, with its precise timestamps, can be used not only for fault location but also for performance analysis. It can easily analyze which stage (cloud, network, vehicle) takes the longest for a single remote control operation, providing accurate data guidance for system performance optimization. The graphical interface allows even newly hired operations and maintenance personnel unfamiliar with the overall system architecture and log formats to quickly get started and effectively troubleshoot problems, significantly reducing training costs and the risk of human error.

[0137] like Figure 4 As shown, in some embodiments, an abnormal status node is also included for monitoring service anomalies in the vehicle-cloud interaction link.

[0138] When the business logic execution of any participant in the link is interrupted or returns to failure due to verification failure, communication timeout, or instruction execution error, an abnormal state node is triggered.

[0139] An abnormal node tracking data is generated at this node, which includes not only the vehicle identification number and message serial number, but also error code, abnormal description information and service identifier of the abnormal occurrence point.

[0140] The abnormal node tracking data is published and stored in an asynchronous manner, and aggregated together with the successful path node data of the same operation to form a link tracking record containing complete success and failure information, providing a direct basis for judging the cause of the fault for the fault diagnosis service.

[0141] In the above embodiments, the logs for successful paths can only tell the user that "the instruction was lost after the vehicle network service platform and before the connection to the platform." However, the logs for abnormal nodes (such as "verification failed: the window status does not meet the opening conditions") can directly tell the user the reason for the failure, avoiding the need to contact developers to interpret the business code logic, and minimizing the mean time to repair (MTTR).

[0142] Remote control failures are often not due to network outages, but rather to business rule verification failures (such as prohibiting window opening at excessive vehicle speeds). This solution fills the gap in simply monitoring network connectivity by monitoring business anomalies, enabling the tracking system to cover 100% of failure scenarios and achieving true comprehensive observability.

[0143] By aggregating abnormal data with successful path data, a "link tracing record containing complete success and failure information" is formed. This allows for not only viewing detailed errors in failed requests during diagnosis but also comparing and analyzing them with successful requests from the same period, providing an unprecedentedly powerful tool for solving complex problems.

[0144] The following is a complete example of end-to-end asynchronous tracing for remotely opening a sunroof:

[0145] (I) System Composition and Scenario Setting

[0146] This embodiment demonstrates how the technical solution of this invention achieves end-to-end tracking when a user performs a "remotely open sunroof" operation on a vehicle via a mobile app. System participants include:

[0147] User side: A smartphone with a vehicle control app installed.

[0148] Cloud:

[0149] Vehicle-to-Everything (TSP) Service Platform: Handles core business logic.

[0150] Connection platform: Responsible for protocol conversion and communication between the cloud and the vehicle.

[0151] Log reporting service: A standalone microservice that provides an application programming interface (API) for log reporting.

[0152] Message queue (Kafka): used as an asynchronous communication channel.

[0153] No relational database (MongoDB): Used to store node tracking data.

[0154] Vehicle side:

[0155] Vehicle T-Box: Vehicle Internet Gateway.

[0156] Sunroof controller: Performs specific control actions.

[0157] Remote control and end-to-end tracing process:

[0158] STEP 1: Tracking the Command Issuance Sequence

[0159] 1.1, (corresponding to the first node) TSP issues remote control commands:

[0160] When the TSP's business processing service receives the App's request to open the window, it generates a global serial number (such as Trace_001) after the verification is successful.

[0161] Before the command is sent to the connection platform, the TSP triggers the first node. The business processing service synchronously calls the log reporting service's API to transmit node tracking data containing information such as the vehicle identification number (VIN), serial number, and node type (TSP_DISPATCH).

[0162] The log reporting service immediately publishes the data asynchronously to Kafka. The TSP's business logic continues to execute, issuing instructions to the connection platform.

[0163] 1.2 (corresponding to the third node) The connection platform sends instructions to the T-Box:

[0164] After receiving the instruction, the connection platform converts it into a dedicated message that the T-Box can recognize.

[0165] Before sending a message to the T-Box, the connection platform triggers a third node. Its business processing service calls the log reporting service to record node tracing data containing information such as protocol type and service code, and asynchronously publishes it to Kafka.

[0166] STEP2: Tracing the Instruction Response Sequence

[0167] 2.1 (Corresponding to the fourth node) T-Box confirms receipt:

[0168] Upon receiving the instruction, the T-Box immediately sends a receipt confirmation message back to the connection platform.

[0169] After the connection platform decodes the confirmation message, it triggers the fourth node to asynchronously record and publish the confirmation information as node tracking data.

[0170] 2.2, (corresponding to the second node) The T-Box returns the final execution result:

[0171] The T-Box issues a command to the sunroof controller. Suppose the controller detects an obstacle and the command fails to execute.

[0172] The T-Box returns the final execution result, including the failure error code, to the connected platform.

[0173] After the connection platform decodes the result message, it triggers the second node to asynchronously record and publish the failure result and error code as node tracking data.

[0174] 2.3 (corresponding to the fifth node) TSP receives the final result:

[0175] The connection platform forwards the final execution result to the TSP.

[0176] After receiving the result, TSP triggers the fifth node to asynchronously record the final state of this remote control operation to its database or publish it to Kafka through a unified path, thus completing the business loop.

[0177] STEP 3: Data Persistence and Aggregation

[0178] All node tracking data transmitted through Kafka is consumed by an independent log consumption service and persistently stored in MongoDB according to preset data standardization mapping rules.

[0179] By using the shared serial number (Trace_001), the system can logically aggregate all node data from this remote control operation into a complete link tracing record.

[0180] STEP4: Fault Diagnosis Process

[0181] Operations personnel can query the VIN and time period through the fault diagnosis service. The system automatically retrieves and aggregates the complete record with the serial number Trace_001 from MongoDB and displays it clearly in the form of a time sequence diagram.

[0182] Link display:

[0183] [First Node] TSP issues command -> [Third Node] Command sent to T-Box -> [Fourth Node] T-Box confirms receipt -> [Second Node] T-Box returns failure result -> [Fifth Node] TSP receives result

[0184] Diagnosis results:

[0185] Maintenance personnel directly observed:

[0186] The command successfully reached the vehicle (fourth node successful).

[0187] The reason for the failure is the specific error code reported by the vehicle (such as "obstacle detection").

[0188] Conclusion: The fault was located at the vehicle's physical level, rather than at the cloud service or network transmission level, achieving precise location within minutes.

[0189] Explanation of the "wake-up" scenario:

[0190] If the vehicle T-Box is initially offline, there is a pre-wake-up sequence.

[0191] Before officially issuing the sunroof opening command, the TSP will first issue a wake-up command.

[0192] The issuance of this wake-up command will be recorded as an independent node (which can be called "node zero"). Its process is similar to the main process described above, but it records the relevant data of the wake-up operation.

[0193] This wake-up sequence is an optional pre-processing step that precedes the main business instruction issuance sequence. The main business's "instruction issuance sequence" will only begin after a successful wake-up.

[0194] Based on the same inventive concept, embodiments of the present invention also provide an electronic device. Figure 5 This is a structural block diagram of an electronic device provided in an embodiment of the present invention. Figure 5 As shown, an embodiment of the present invention provides an electronic device including: one or more processors 101, a memory 102, and one or more I / O interfaces 103. The memory 102 stores one or more programs, which, when executed by the one or more processors, enable the one or more processors to implement an asynchronous tracking method for a vehicle remote control link as described in any of the above embodiments; the one or more I / O interfaces 103 are connected between the processor and the memory, configured to enable information interaction between the processor and the memory.

[0195] The processor 101 is a device with data processing capabilities, including but not limited to a central processing unit (CPU); the memory 102 is a device with data storage capabilities, including but not limited to random access memory (RAM, more specifically SDRAM, DDR, etc.), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), and flash memory (FLASH); the I / O interface (read / write interface) 103 is connected between the processor 101 and the memory 102, and can realize information interaction between the processor 101 and the memory 102, including but not limited to a data bus (Bus).

[0196] In some embodiments, the processor 101, memory 102, and I / O interface 103 are interconnected via bus 104, and thus connected to other components of the computing device.

[0197] In some embodiments, the one or more processors 101 include a field-programmable gate array.

[0198] This invention also provides a computer-readable medium. The computer-readable medium stores a computer program, which, when executed by a processor, implements the steps in any of the asynchronous tracking methods for a vehicle remote control link described in the above embodiments. The computer-readable storage medium may be volatile or non-volatile.

[0199] This invention also provides a computer program product, including computer-readable code, or a non-volatile computer-readable storage medium carrying computer-readable code. When the computer-readable code is run in the processor of an electronic device, the processor in the electronic device executes the above-described asynchronous tracking method for a vehicle remote control link.

[0200] Those skilled in the art will understand that all or some of the steps, systems, and apparatuses disclosed above, and their functional modules / units, can be implemented as software, firmware, hardware, or suitable combinations thereof. In hardware implementations, the division between functional modules / units mentioned above does not necessarily correspond to the division of physical components; for example, a physical component may have multiple functions, or a function or step may be performed collaboratively by several physical components. Some or all physical components may be implemented as software executed by a processor, such as a central processing unit, digital signal processor, or microprocessor, or as hardware, or as an integrated circuit, such as an application-specific integrated circuit (ASIC). Such software can be distributed on a computer-readable storage medium, which may include computer storage media (or non-transitory media) and communication media (or transient media).

[0201] As is known to those skilled in the art, the term computer storage medium includes volatile and non-volatile, removable and non-removable media implemented in any method or technology for storing information, such as computer-readable program instructions, data structures, program modules, or other data. Computer storage media includes, but is not limited to, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM), static random access memory (SRAM), flash memory or other memory technologies, portable compact disc read-only memory (CD-ROM), digital versatile disc (DVD) or other optical disc storage, magnetic cartridges, magnetic tape, disk storage or other magnetic storage devices, or any other medium that can be used to store desired information and is accessible to a computer. Furthermore, it is known to those skilled in the art that communication media typically contain computer-readable program instructions, data structures, program modules, or other data in modulated data signals such as carrier waves or other transmission mechanisms, and may include any information delivery medium.

[0202] The computer-readable program instructions described herein can be downloaded from computer-readable storage media to various computing / processing devices, or downloaded via a network, such as the Internet, local area network, wide area network, and / or wireless network, to an external computer or external storage device. The network may include copper transmission cables, fiber optic transmission, wireless transmission, routers, firewalls, switches, gateway computers, and / or edge servers. A network adapter card or network interface in each computing / processing device receives the computer-readable program instructions from the network and forwards them to the computer-readable storage media in the respective computing / processing device.

[0203] The computer program instructions used to perform the operations of this invention may be assembly instructions, instruction set architecture (ISA) instructions, machine instructions, machine-dependent instructions, microcode, firmware instructions, state setting data, or source code or object code written in any combination of one or more programming languages, including object-oriented programming languages ​​such as Smalltalk, C++, etc., and conventional procedural programming languages ​​such as the "C" language or similar programming languages. The computer-readable program instructions may be executed entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In cases involving a remote computer, the remote computer may be connected to the user's computer via any type of network—including a local area network (LAN) or a wide area network (WAN)—or may be connected to an external computer (e.g., via the Internet using an Internet service provider). In some embodiments, electronic circuitry, such as programmable logic circuitry, field-programmable gate arrays (FPGAs), or programmable logic arrays (PLAs), is personalized by utilizing state information from the computer-readable program instructions. This electronic circuitry can execute the computer-readable program instructions to implement various aspects of the invention.

[0204] The computer program product described herein can be implemented specifically through hardware, software, or a combination thereof. In one alternative embodiment, the computer program product is specifically embodied in a computer storage medium; in another alternative embodiment, the computer program product is specifically embodied in a software product, such as a software development kit (SDK), etc.

[0205] Various aspects of the present invention are described herein with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the invention. It should be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer-readable program instructions.

[0206] These computer-readable 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, when executed by the processor of the computer or other programmable data processing apparatus, they create means for implementing the functions / actions specified in one or more blocks of the flowchart and / or block diagram. These computer-readable program instructions can also be stored in a computer-readable storage medium that causes a computer, programmable data processing apparatus, and / or other device to operate in a particular manner; thus, the computer-readable medium storing the instructions comprises an article of manufacture that includes instructions for implementing aspects of the functions / actions specified in one or more blocks of the flowchart and / or block diagram.

[0207] Computer-readable program instructions may also be loaded onto a computer, other programmable data processing apparatus, or other device to cause a series of operational steps to be performed on the computer, other programmable data processing apparatus, or other device to produce a computer-implemented process, thereby causing the instructions executed on the computer, other programmable data processing apparatus, or other device to perform the functions / actions specified in one or more boxes of a flowchart and / or block diagram.

[0208] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of the present invention. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of an instruction, which contains one or more executable instructions for implementing a specified logical function. In some alternative implementations, the functions marked in the blocks may occur in a different order than those shown in the drawings. For example, two consecutive blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, may be implemented using a dedicated hardware-based system that performs the specified function or action, or using a combination of dedicated hardware and computer instructions.

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

Claims

1. An asynchronous tracking method for a vehicle remote control link, characterized in that, The method includes the following steps: The cloud service platform defines multiple key tracking nodes, which cover the lifecycle stages of remote control command issuance, transmission, response, and exception handling. At each of the key tracking nodes, standardized node tracking data is generated, which includes at least a vehicle identification code for uniquely identifying the vehicle and a message serial number for associating the entire chain of a single operation. By using asynchronous calls, the node tracking data is published to a designated topic in the message queue system, ensuring that the processing of the main remote control business is not blocked by log recording operations; By listening to the message queue topic through an independent log consumption service, the acquired node tracing data is persisted to a non-relational database to form a complete link tracing record for fault diagnosis.

2. The method according to claim 1, characterized in that, The key tracking nodes include at least a sequence node for monitoring the forward propagation of remote control commands and a response sequence node for monitoring the reverse feedback of command execution results. The issued sequence nodes and the response sequence nodes together constitute the basic timing framework for tracking the entire lifecycle of the vehicle-cloud interaction.

3. The method according to claim 2, characterized in that, The sequence nodes to be distributed include at least a first node and a third node; The first node is located when the vehicle network service platform sends a remote control command to the connection platform after completing the command verification and encapsulation. The third node is located when the connection platform converts the remote control command into a vehicle-readable message and sends it to the vehicle T-Box; The first node and the third node, according to the instruction issuance sequence, form the critical path of the forward propagation process.

4. The method according to claim 3, characterized in that, The method further includes: defining a wake-up sequence before the start of the sending sequence node; When the vehicle networking service platform determines that the target vehicle's in-vehicle T-Box is offline, the wake-up sequence is triggered; In this wake-up sequence, when the vehicle network service platform generates and issues the T-Box wake-up command, wake-up tracking data containing the vehicle identification code and wake-up serial number is generated and asynchronously published to the message queue system as independent node tracking data.

5. The method according to claim 4, characterized in that, The response sequence nodes include at least a second node, a fourth node, and a fifth node; The second node is located when the connection platform receives the final execution result of the instruction returned by the vehicle-mounted T-Box; the fourth node is located when the connection platform receives the confirmation response of the vehicle-mounted T-Box to the instruction, and it is earlier than the second node in terms of timing. The fifth node is located when the vehicle network service platform receives the final execution result of the instruction forwarded by the connection platform, and it is later than the second node in time sequence; The fourth, second, and fifth nodes, in accordance with the command response sequence, together constitute the complete path of the reverse feedback process, with the fifth node serving as the end point of the full-link tracking for a single remote control operation.

6. The method according to claim 1, characterized in that, The asynchronous call is implemented through a decoupled microservice architecture that isolates the business processing service that generates node tracing data from the log reporting service that is responsible for log communication in terms of processes. When a critical tracing node is triggered, the business processing service calls the application interface of the log reporting service through cross-process communication and transmits the standardized node tracing data. The log reporting service is configured to immediately publish the data to the message queue system in a non-blocking asynchronous manner after receiving the data.

7. The method according to claim 1, characterized in that, The persistence process includes a data standardization mapping rule; The log consumption service is configured to map JSON-formatted node tracking data in the message queue into a document model suitable for a non-relational database according to predefined rules. The document model predefines several core fields, including at least: a) Vehicle identification number (VIN) serves as the primary partition key for data retrieval; b) The message serial number serves as the association key for tracking data across all nodes under the same remote control operation; c) Node timestamps, used to determine the timing of nodes within a single operation; d) Node type identifier, used to distinguish the logical role of a node in the business chain; e) Data payload, used to store node-specific business information. By using mapping rules, heterogeneous node data is transformed into documents with a unified structure and written to a non-relational database.

8. The method according to claim 7, characterized in that, Also includes: Provide a fault diagnosis service based on the complete link tracing record; The fault diagnosis service receives a diagnosis request through a query interface, and the diagnosis request includes at least the target vehicle identification code and the query time range. The fault diagnosis service is configured to perform the following operations: a) Based on the vehicle identification number and time range, retrieve all relevant documents from the non-relational database; b) Based on the message serial number in the document model, aggregate all node tracking documents belonging to the same remote control operation to generate a complete link tracking record; c) For the aggregated link tracing records, sort them in time sequence according to the node timestamps in the document model, and parse the node type identifier and data payload; d) Visualize the parsed results to present the complete propagation path of remote control commands, the status of each node, and the time consumption in a graphical interface, thereby enabling rapid fault location and performance analysis.

9. The method according to claim 8, characterized in that, The key tracking nodes also include abnormal status nodes used to monitor business anomalies in the vehicle-cloud interaction link. When the business logic execution of any participant in the link is interrupted or returns to failure due to verification failure, communication timeout, or instruction execution error, an abnormal state node is triggered. An abnormal node tracking data is generated at this node, which includes not only the vehicle identification number and message serial number, but also error code, abnormal description information and service identifier of the abnormal occurrence point. The abnormal node tracking data is published and stored in an asynchronous manner, and aggregated together with the successful path node data of the same operation to form a link tracking record containing complete success and failure information, providing a direct basis for judging the cause of the fault for the fault diagnosis service.

10. An electronic device, characterized in that, include: One or more processors; Memory, used to store one or more programs; When the one or more programs are executed by the one or more processors, the one or more processors implement the method as described in any one of claims 1 to 9.

Images