A vehicle networking network diagnosis method and electronic equipment

Abstract

The application provides a vehicle networking network diagnosis method, comprising the following steps: receiving a network diagnosis request and parsing the network diagnosis request into a task object; constructing a four-layer context object according to the task object; linking a rule engine and a large language model to generate a diagnosis execution plan of a current stage based on the four-layer context object; calling a tool to query a network condition on demand according to the diagnosis execution plan of the current stage to generate a query result of the current stage; compressing the query result of the current stage to generate a stage state memory of the current stage, and appending the stage state memory of the current stage to a stage state memory chain of the current stage; loading the stage state memory of the current stage and a preset termination rule set for matching, and if a matching result meets a preset condition, the network diagnosis is terminated, and a network diagnosis report is generated. The scheme provided by the application can greatly reduce invalid interface calls, reduce large model inference costs, and improve complex fault diagnosis accuracy.

Description

Technical Field

[0001] This invention relates to the field of vehicle-to-everything (V2X) technology, and in particular to a V2X network diagnostic method, system, and electronic device. Background Technology

[0002] Vehicle-to-everything (V2X) is an intelligent automotive application system based on Internet of Things (IoT) technology. It equips vehicles with SIM (SIM card) cards (including eSIM, MIM, etc.) to enable functions such as vehicle-to-everything (V2X) connectivity, T-BOX (Telematics Unit) data communication, OTA (Over-The-Air) upgrades, and remote control. During the large-scale operation of V2X, SIM network failures are a frequent issue affecting user experience and platform stability, typically manifesting as no network access for the vehicle's infotainment system, dial-up failures, and abnormal data usage.

[0003] Currently, fault location in vehicle-to-everything (V2X) SIM networks typically relies on manual troubleshooting by the operator's platform or the V2X backend. Technicians need to check information from multiple dimensions, such as the SIM card's lifecycle status, public network access status, real-name authentication status, data usage status, and dialing records, to gradually eliminate possible causes of the fault.

[0004] With the continuous improvement of the capabilities of large language models in artificial intelligence, combining LLM (Large Language Model) with tool calls and rule engines in an agent-based approach to automate complex diagnostic tasks has become an important technological direction in the field of industrial intelligent operation and maintenance. However, how to effectively control the computational cost of agents, reduce ineffective tool calls, and build a sustainable optimization experience loop while ensuring diagnostic accuracy remains the core engineering challenge facing this direction. Summary of the Invention

[0005] The purpose of this invention is to provide a method and electronic device for vehicular network diagnosis, which can significantly reduce invalid interface calls, reduce the inference cost of large models, and improve the accuracy of complex fault diagnosis.

[0006] This application provides a method for vehicular network diagnosis, including the following steps: receiving a network diagnosis request and parsing the request into a task object; constructing a four-layer context object based on the task object, wherein the four-layer context object is obtained by merging a global context layer, a task context layer, a dynamic state context layer, and a rule context layer; linking a rule engine and a large language model to generate a diagnosis execution plan for the current stage based on the four-layer context object; calling tools as needed to query network conditions according to the diagnosis execution plan for the current stage, and generating query results for the current stage; the on-demand call to the business interface is to only call the tools listed in the diagnosis execution plan for the current stage; compressing the query results for the current stage to generate a stage state memory for the current stage, and appending the stage state memory for the current stage to the stage state memory chain for the current stage; loading the stage state memory for the current stage and matching it with a preset termination rule set; if the matching result meets the preset conditions, terminating the network diagnosis and generating a network diagnosis report.

[0007] In one embodiment, if the matching result does not meet the preset conditions, the rule engine and the large language model are re-linked to generate a diagnostic execution plan for the next stage based on the four-layer context object, and the next stage of network diagnosis is performed.

[0008] In one embodiment, generating the diagnostic execution plan for the next stage based on the four-layer context objects includes: generating the diagnostic execution plan for the next stage based on the four-layer context objects and the stage state memory chain of the already executed stages.

[0009] In one embodiment, the matching result satisfying preset conditions includes: the matching result is a match for any termination rule, or the matching result is a completion of all diagnostic stages but no termination rule is matched, or the matching result is the maximum number of diagnostic stages reached but no termination rule is matched.

[0010] In one embodiment, before generating the network diagnostic report, the method further includes: performing context pruning, discarding all context data of unexecuted phases; and recording the diagnostic link length of executed phases into the phase state memory chain of the final phase.

[0011] In one embodiment, generating a network diagnostic report includes: generating a network diagnostic report based on the stage state memory chain and diagnostic conclusion labels of the final stage.

[0012] In one embodiment, the task object includes a SIM identifier, a vehicle identifier, and a fault description.

[0013] In one embodiment, after generating the network diagnostic report, the method further includes: storing the task object, the stage state memory chain of each stage, the diagnostic conclusion, the diagnostic conclusion label, the actual execution tool call order, the diagnostic link length, and the termination rule hit status into a history memory database; and establishing a retrieval index for the history database with the SIM identifier, vehicle identifier, and fault description.

[0014] In one embodiment, after generating the network diagnostic report, the method further includes: when a new diagnostic request is received, retrieving the historical memory based on the SIM identifier, vehicle identifier, and fault description, selecting a historical diagnostic path with a similarity exceeding a preset similarity threshold, and generating a diagnostic execution plan corresponding to the new diagnostic request based on the historical diagnostic path.

[0015] This application also provides an electronic device, which includes: a processor; and a memory for storing processor-executable instructions; wherein the processor is configured to execute the above-described vehicle network diagnostic method.

[0016] The method provided in the above embodiments of this application significantly reduces invalid interface calls, lowers the reasoning cost of large models, and improves the accuracy of complex fault diagnosis by hierarchical context management, stage state memory, rule and large model collaborative reasoning, dynamic pruning of diagnostic links and historical memory reuse closed loop. At the same time, it outputs multi-role differentiated diagnostic reports and realizes continuous self-optimization of the system, effectively solving various defects of existing vehicle network SIM diagnostic solutions such as resource waste, missed diagnosis, lack of experience accumulation and poor readability of results. Attached Figure Description

[0017] To more clearly illustrate the technical solutions of the embodiments of this application, the accompanying drawings used in the embodiments of this application will be briefly described below.

[0018] Figure 1 This is a flowchart of a vehicle-to-everything (V2X) network diagnostic method in related technologies; Figure 2 This is a flowchart of another vehicle-to-everything (V2X) network diagnostic method in related technologies; Figure 3 This is a schematic diagram of the structure of the electronic device provided in the embodiments of this application; Figure 4 This is a flowchart of a vehicle network diagnostic method provided in an embodiment of this application; Figure 5 This is a flowchart of another vehicle network diagnostic method provided in the embodiments of this application; Figure 6 This is an architecture diagram of the vehicle network diagnostic system provided in the embodiments of this application. Detailed Implementation

[0019] The technical solutions in the embodiments of this application will now be described with reference to the accompanying drawings.

[0020] Similar reference numerals and letters in the following figures indicate similar items; therefore, once an item is defined in one figure, it does not need to be further defined and explained in subsequent figures. Furthermore, in the description of this application, terms such as "first," "second," etc., are used only to distinguish descriptions and should not be construed as indicating or implying relative importance.

[0021] Before introducing the solutions of the embodiments of this application, the key concepts involved will be explained as follows: The Internet of Vehicles (IoV) is an Internet of Things (IoT) application system that connects vehicles, roads, pedestrians, and cloud platforms through wireless communication technology to achieve functions such as vehicle status collection, remote control, and network communication.

[0022] SIM card: Subscriber Identity Module (SIM) is a physical or embedded identity card provided by operators for in-vehicle communication equipment in the Internet of Vehicles (IoV). It carries the vehicle's mobile network access capability and has core attributes such as lifecycle management, public network access, and data plans.

[0023] Agent (Intelligent Agent): In the field of artificial intelligence, an automated system capable of perceiving environmental states, autonomously planning actions, and invoking tools to complete complex goals. In this solution, "Agent" specifically refers to a diagnostic service unit with capabilities for hierarchical context understanding, tool invocation, rule-based collaborative reasoning, and result generation.

[0024] Context Management: In large-scale model inference systems, this is a mechanism for organizing, filtering, trimming, and dynamically loading the information required by the agent during the inference process, used to control the input length and inference quality of the model.

[0025] Phase State Memory: The core data structure proposed in this solution refers to compressing the original query results into structured summary information after each diagnostic phase, which can be consumed by subsequent phases, replacing the lengthy full dialogue history.

[0026] Rule Engine: The component in the system responsible for matching and judging the current state based on a predefined set of rules. It is used to determine whether to trigger termination conditions, stage switching, or action routing, and works with the large model to jointly control the diagnostic process.

[0027] Large Language Model (LLM): A large-scale pre-trained language model based on the Transformer architecture, possessing capabilities such as natural language understanding, logical reasoning, and task planning. In this solution, it is used for natural language generation for task understanding, stage planning, and diagnostic results.

[0028] Lifecycle status: The operator's status indicator for the current service stage of the SIM card, which usually includes the usage period, suspension period, number retention period, maintenance period, cancellation period, etc., and directly affects the network access capability of the SIM card.

[0029] Public network switch: This is a control switch on the vehicle network platform or operator side to grant SIM cards public network access permissions. It can be either on or off. When off, the SIM card cannot access the public internet.

[0030] Real-name authentication status: This is the status of SIM card holders verifying their real identity as required by law and regulations. SIM cards that have not completed real-name authentication will not be able to provide normal network services.

[0031] As mentioned above, during the large-scale operation of the Internet of Vehicles, SIM network failure is a high-frequency problem that affects user experience and platform stability. The solutions to this problem in related technologies are mainly divided into two types: manual troubleshooting and automated diagnosis based on traditional rules.

[0032] In manual troubleshooting mode, maintenance personnel sequentially query SIM lifecycle, public network access, real-name authentication, data plan, and all dialing logs. Even if the fault can be located early, the entire query process still needs to be executed, consuming significant amounts of carrier interface resources and resulting in high diagnostic latency. Taking the handling of "no network connection in the vehicle" fault report by a vehicle-to-everything (V2X) platform as an example, such as... Figure 1 The diagram shows a flowchart of a vehicle-to-everything (V2X) network diagnostic method. Current SIM network fault diagnosis methods involve technicians receiving a work order and then sequentially checking the following: SIM card lifecycle status → public network access status → real-name authentication status → data usage status and data plan → dialing records and logs. After each step, technicians manually determine whether to continue. Theoretically, if the cause is clear at a certain step (e.g., the SIM card is found to be in a retention period), subsequent checks can be stopped. However, due to the lack of a systematic termination mechanism, in practice, the entire query chain is often executed.

[0033] Traditional rule-based automated diagnostic models, employing fixed if-else rule engines, can only cover simple single-factor faults. Complex boundary scenarios, such as multiple faults overlapping or inconsistent configurations, are prone to missed or incorrect diagnoses. Introducing large language models to assist in reasoning involves inputting all raw query logs into the model at once, resulting in severe contextual text redundancy that exceeds the model's reasoning window, significantly increasing token computation costs and decreasing reasoning accuracy. Currently, some connected vehicle platforms have attempted to implement partial automated diagnostics using rule scripts or process engines, such as... Figure 2 The diagram shows a flowchart of another vehicle-to-everything (V2X) network diagnostic method. Its operation involves pre-defining several if-else branch rules, evaluating each query result, and finally providing a processing suggestion. The rules of this type of system operate as follows: when the lifecycle query returns "number retention period," it returns a "number retention period network suspension" conclusion; when the public network switch is off, it returns a "public network disabled" conclusion; if none of the above are abnormal, it continues to query traffic and dialing records until a matching rule is found.

[0034] In summary, the relevant technologies for vehicle network diagnostics have the following shortcomings: 1. The query path is fixed and lacks dynamic trimming capabilities.

[0035] Regardless of whether the problem has been located in an early stage, the relevant systems execute all query steps in a preset fixed order, resulting in a large number of unnecessary interface calls, which increases system response latency and interface resource consumption.

[0036] 2. The rules and logic are rigid and cannot cover complex combination scenarios.

[0037] Diagnostic systems based on if-else rules can only handle predefined single-factor or simple combination scenarios. For complex situations such as multiple factors overlapping or historical fault associations, the rule coverage is insufficient, which can easily lead to missed or incorrect judgments.

[0038] 3. Lack of context management leads to high integration costs for large models.

[0039] When large language models are introduced to handle diagnostic tasks, related solutions typically input all query results into the model at once, resulting in contextual redundancy, exceeding the model's effective inference window, reducing inference quality, and incurring high token costs.

[0040] 4. Lack of stateful memory, resulting in inefficient information transfer between stages.

[0041] The relevant system lacks a structured state transfer mechanism between stages, does not retain intermediate conclusions after each diagnosis, cannot support continuous reasoning across stages, and cannot reuse historical diagnostic experience for subsequent similar problems.

[0042] 5. The diagnostic results are uninterpretable and lack structured output.

[0043] The relevant rule system can usually only output a binary conclusion of "whether it is faulty" and cannot generate differentiated diagnostic descriptions for users, customer service and operation and maintenance, which is not conducive to the flow of work orders and communication with users.

[0044] To address the aforementioned shortcomings, this application provides a vehicle network diagnostic method that significantly reduces invalid interface calls, lowers the cost of large model inference, and improves the accuracy of complex fault diagnosis by implementing hierarchical context management, stage state memory, rule-based and large model collaborative reasoning, dynamic pruning of diagnostic links, and historical memory reuse closed loop. Simultaneously, it outputs multi-role differentiated diagnostic reports and enables continuous system self-optimization, effectively solving various defects in existing vehicle network SIM diagnostic solutions, such as resource waste, missed diagnoses, lack of experience accumulation, and poor result readability.

[0045] Figure 3 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. The electronic device 100 can be used to execute the vehicle network diagnostic method provided in an embodiment of this application. Figure 3 As shown, the electronic device 100 includes: one or more processors 102 and one or more memories 104 storing processor-executable instructions. The processors 102 are configured to execute the vehicle network diagnostic method provided in the following embodiments of this application.

[0046] The processor 102 may be a gateway, a smart terminal, or a device that includes a central processing unit (CPU), a graphics processing unit (GPU), or other forms of processing units with data processing capabilities and / or instruction execution capabilities. It can process data from other components in the electronic device 100 and control other components in the electronic device 100 to perform desired functions.

[0047] The memory 104 may include one or more computer program products, which may include various forms of computer-readable storage media, such as volatile memory and / or non-volatile memory. The volatile memory may include, for example, random access memory (RAM) and / or cache memory. The non-volatile memory may include, for example, read-only memory (ROM), hard disk, flash memory, etc. One or more computer program instructions may be stored on the computer-readable storage medium, and the processor 102 may execute the program instructions to implement the vehicle network diagnostic method described below. Various application programs and various data may also be stored in the computer-readable storage medium, such as various data used and / or generated by the application programs.

[0048] In one embodiment, Figure 3 The illustrated electronic device 100 may further include an input device 106, an output device 108, and a data acquisition device 110, these components being interconnected via a bus system 112 and / or other forms of connection mechanisms (not shown). It should be noted that... Figure 3 The components and structure of the electronic device 100 shown are merely exemplary and not limiting; the electronic device 100 may also have other components and structures as needed.

[0049] The input device 106 may be a device used by a user to input commands, and may include one or more of a keyboard, mouse, microphone, and touchscreen. The output device 108 may output various information (e.g., images or sounds) to the outside (e.g., the user), and may include one or more of a display, speaker, etc. The data acquisition device 110 may acquire network diagnostic requests, etc., and store the acquired data in the memory 104 for use by other components.

[0050] In one embodiment, the components in the example electronic device 100 used to implement the vehicle network diagnostic method of the present application embodiment can be integrated or distributed. For example, the processor 102, memory 104, input device 106 and output device 108 can be integrated into one unit, while the data acquisition device 110 can be separated.

[0051] In one embodiment, the example electronic device 100 for implementing the vehicle network diagnostic method of the present application embodiment can be implemented as a smart terminal such as a smartphone, tablet computer, desktop computer, server, vehicle equipment, etc.

[0052] Figure 4 This is a flowchart of a vehicle network diagnostic method provided in an embodiment of this application. Figure 4 In this method, steps S210-260 are included.

[0053] Step 210: Receive a network diagnostic request and parse the network diagnostic request into a task object.

[0054] In one embodiment, step 210 is performed by the task access module.

[0055] In one embodiment, the task object includes a SIM identifier, a vehicle identifier, and a fault description.

[0056] Step 220: Based on the task object, construct a four-layer context object, which is obtained by merging the global context layer, task context layer, dynamic state context layer, and rule context layer.

[0057] In one embodiment, step 220 is performed by the hierarchical context building module.

[0058] Step 230: Link the rule engine and the large language model to generate a diagnostic execution plan for the current stage based on the four-layer context objects.

[0059] In one embodiment, step 230 is performed by the Agent inference planning module.

[0060] Step 240: Based on the current stage's diagnostic execution plan, call tools as needed to query network conditions and generate query results for the current stage; the on-demand call business interface only calls the tools listed in the current stage's diagnostic execution plan.

[0061] In one embodiment, step 240 is performed by the tool calling module.

[0062] Step 250: Compress the query results of the current stage to generate the stage state memory of the current stage, and append the stage state memory of the current stage to the stage state memory chain of the current stage.

[0063] In one embodiment, step 250 is performed by the stage state memory module.

[0064] Step 260: Load the current stage state memory and match it with the preset termination rule set. If the matching result meets the preset conditions, terminate the network diagnosis and generate a network diagnosis report.

[0065] In one embodiment, in step 260, the current stage state memory is loaded and matched with a preset termination rule set. If the matching result meets the preset conditions, the termination of network diagnosis is completed by the termination determination module. In step 260, the generation of the network diagnosis report is completed by the result generation module.

[0066] In one embodiment, the current stage state memory is loaded and matched with a preset termination rule set. If the matching result does not meet the preset conditions, the rule engine and the large language model are re-linked, and a diagnostic execution plan for the next stage is generated based on the four-layer context object, and network diagnosis for the next stage is performed.

[0067] In one embodiment, generating the diagnostic execution plan for the next stage based on the four-layer context objects includes: generating the diagnostic execution plan for the next stage based on the four-layer context objects and the stage state memory chain of the already executed stages.

[0068] In one embodiment, the matching result meeting preset conditions includes: the matching result is a match for any termination rule, or the matching result is a completion of all diagnostic stages but no termination rule is matched, or the matching result is the maximum number of diagnostic stages reached but no termination rule is matched.

[0069] In one embodiment, before generating the network diagnostic report, the method further includes: performing context pruning, discarding all context data of unexecuted phases; and recording the diagnostic link length of executed phases into the phase state memory chain of the final phase.

[0070] In one embodiment, generating a network diagnostic report includes: generating a network diagnostic report based on the stage state memory chain and diagnostic conclusion labels of the final stage.

[0071] In one embodiment, after generating the network diagnostic report, the method further includes: storing the task object, the stage state memory chain of each stage, the diagnostic conclusion, the diagnostic conclusion label, the actual tool call order, the diagnostic link length, and the termination rule hit status into a historical memory database; and establishing a retrieval index for the historical memory database along with the SIM identifier, vehicle identifier, and fault description. This step is performed by the historical memory accumulation module.

[0072] In one embodiment, after generating the network diagnostic report, the method further includes: when a new diagnostic request is received, retrieving the historical memory database based on the SIM identifier, vehicle identifier, and fault description, and selecting a historical diagnostic path with a similarity exceeding a preset similarity threshold; and generating a diagnostic execution plan corresponding to the new diagnostic request based on the historical diagnostic path. This step is performed by the historical memory retrieval module.

[0073] Figure 5 This is a flowchart of another vehicle network diagnostic method provided in an embodiment of this application, which includes steps S1-S10.

[0074] Step S1: Receive diagnostic task. This includes the following steps: Step 101: The task access module receives diagnostic requests from sources such as customer service system, operation and maintenance platform, vehicle-mounted system reporting or automatic inspection.

[0075] Step 102: Parse the external request into a standardized task object. The task object structure contains the following fields: { "task_id": "DIAG-2025-001", "sim_id": "8966XXXXXXXXXXXX", "vehicle_id": "VIN-XXXXXXXXX", "trigger_type": "customer_complaint", "problem_description": "In-vehicle infotainment system lacks network connectivity", "source_channel": "customer_service", "priority": "high", "trigger_time": "2025-08-26T11:18:53+08:00" } Step 103: Assign tasks to the corresponding processing queues according to priority tags. High-priority tasks (such as security-related anomalies and important customer work orders) enter the real-time queue, while ordinary tasks enter the batch processing queue.

[0076] Step S2: Construct the initial hierarchical context. This includes the following steps: Step 201: The hierarchical context construction module loads the global context layer from the basic information system based on sim_id (SIM identifier) ​​and vehicle_id (vehicle identifier) ​​to carry the factual basis, including: SIM card basic attributes (card number, operator, package type, network access time), vehicle basic information (vehicle model, license plate, vehicle ID), device binding relationship (T-BOX device ID, vehicle ID), historical suspension and resumption records (the last three, including time and reason), historical diagnostic conclusions (the last three, including conclusion tags and handling results; only a shallow summary is loaded here, without the state memory chain of each stage and historical tool call path, for the Agent to quickly understand the historical background), and platform rule version number.

[0077] Step 202: Construct a task context layer based on the current task to carry task information, including: description of the current fault report, initiation time, current problem tag (such as "no network in the vehicle", "weak signal", "dialing failure"), source channel, task priority, and current phase number (initial value is phase_0).

[0078] Step 203: Initialize an empty dynamic state context layer to hold the running state, which will be gradually filled in by subsequent tool calls.

[0079] Step 204: Load the current version of the rule context layer to carry the rule constraints, including: termination rule set (listing all known combinations of states that can be terminated early), stage entry rule set (specifying the triggering conditions for each stage), tool call priority rule (specifying the recommended call order for each tool), result mapping rule (mapping state combinations to standard conclusion labels), and risk level rule (determining whether upgrade processing or manual intervention is required).

[0080] Step 205: Merge the above four layers of context into a structured context object, which will then be used as input for the subsequent Agent inference module.

[0081] Step S3: Generate the first-stage plan (Agent inference). This includes the following steps: Step 301: The Agent reasoning and planning module takes the current hierarchical context object and the initial task template as input, and the large language model and rule engine work together to generate the first-stage diagnostic plan.

[0082] Step 302: The rule engine determines the optimal combination of query tools for the current stage based on the tool call priority rules. For issues like "no network connection in the vehicle's infotainment system," the initial rule recommendation prioritizes querying the following two items simultaneously: `lifecycle_query`: SIM card lifecycle status query; `public_network_switch_query`: Query the status of the public network switch.

[0083] The two queries mentioned above have low cost and high diversion value, enabling the highest proportion of early termination with minimal cost. If the rule engine cannot determine the tool combination at the current stage (e.g., the issue label exceeds the coverage of the rule priority table, or the state combination in the previous stage state memory has no corresponding rule branch), it switches to LLM inference mode: LLM takes the current hierarchical context and the previous stage memory chain as input, autonomously infers and generates a tool invocation suggestion list, and the rule engine performs compliance verification on the list (confirming that the tool list is within the callable range and the invocation order complies with security constraints) before execution.

[0084] Step 303: The LLM understands the task objective based on the current context and generates a diagnostic approach description for the current stage, which serves as the semantic basis for subsequent report generation. If the current stage is a continuation stage (not the first stage), the LLM also reviews the state memory chain of the previous stage and updates the diagnostic approach based on the existing reasoning conclusions to avoid repeating reasoning with the previous stage.

[0085] Step 304, the Agent outputs the first-stage execution plan, including: The goal for this phase is to confirm whether the basic services of the SIM card are functioning correctly. Tools list for this phase: `[lifecycle_query,public_network_switch_query]`; This phase focuses on the following fields: `lifecycle_status` and `public_network_switch`.

[0086] Step S4: Execute the tool call. This includes the following steps: Step 401: The tool calling module initiates an actual query request to the business interface based on the current stage execution plan.

[0087] Step 402: Tool invocation follows the "on-demand invocation" principle, invoking only the tools listed in the current phase plan and not performing additional full queries.

[0088] Step 403: For each tool call, the following information is written to the tool call log (in a separate operations and maintenance log layer, not loaded into the Agent inference context): tool name, call time, request parameters, complete response body, response time, and call status (success / failure / timeout). The tool call log is used for operations and maintenance auditing and fault traceability. It has a different storage purpose and storage level than the stage status memory generated in step S5, and they do not interfere with each other.

[0089] In step 401, the list of tools that can be invoked in the current stage includes, but is not limited to: `lifecycle_query`: Queries the lifecycle status of a SIM card, returning an enumeration of {in use period, suspension period, number retention period, repair period, cancellation period}. `public_network_switch_query`: Queries the status of the public network switch, returning an enumeration of {on, off}; `realname_auth_query`: Queries the real-name authentication status, returning an enumeration of {authenticated, unauthenticated, authentication failed}; `traffic_status_query`: Queries traffic status and returns the remaining traffic for the current period, the total amount of data in the plan, and whether the network will be suspended if the data limit has been reached. `traffic_history_query`: Queries traffic consumption details for the past 7 days; `dial_record_query`: Queries dialing records and failure reason codes for the past 24 hours; `device_log_query`: Queries network-related logs from the vehicle-side device over the past 24 hours; `network_status_query`: Queries the vehicle's recent network connection status as recorded on the cloud platform; `order_history_query`: Queries historical work orders and their processing records.

[0090] Step 404: The query results are written to the corresponding fields in the dynamic state context layer for use in subsequent memory generation.

[0091] Step S5: Generate stage state memory. This specifically includes the following steps: Step 501: After the current stage tool is invoked, the stage state memory module compresses the original query results into a structured stage state memory.

[0092] Step 502, the stage state memory includes the following fields: { "task_id": "DIAG-2025-001", "sim_id": "8966XXXXXXXXXXXX", "phase_id": "phase_1", "queried_items": ["lifecycle_status", "public_network_switch"], "core_status_values": { "lifecycle_status": "Number retention period", "public_network_switch": "Off" }, "preliminary_conclusion": "The SIM card is in its number retention period, and public network access is disabled. This appears to be a normal network suspension scenario." "phase_status": "pending_rule_check", "next_action": "rule_evaluation", "confidence_score": 0.92, "reason_trace": "Querying lifecycle_status=number retention period, public_network_switch=off, satisfies the prediction conditions of rule R-001a", "recommendation_seed": "Renewal restored" } The phase_status field describes the processing status of the current stage, with the following possible values: "pending_rule_check" (the current stage query has been completed and is awaiting rule determination), "rule_matched" (the termination rule has been hit, and stop_flag will be set to true in step S6), and "continue" (the termination rule has not been hit, and the process continues to the next stage). The stop_flag is an independent boolean field that is set by the termination determination module (step S6) when a rule is hit, and it is not initially present in the stage status memory.

[0093] Step 503: The stage state memory does not retain the original response body data, but only retains key state fields and summary conclusions to control the context length of subsequent agent inference. The complete response body of the tool call has been independently written to the tool call log by step S4 for operation and maintenance auditing; the stage state memory only contains structured key fields extracted from the original response, and the two have separate responsibilities, serving the execution of the current stage and the planning of subsequent stages respectively.

[0094] Step 504: The stage state memory is added to the memory chain of the current task for use by the termination determination module and the Agent planning module of subsequent stages.

[0095] Step S6: Perform the termination determination. This includes the following steps: Step 601: The termination determination module uses the current stage state memory and the termination rule set of the rule context layer as input to perform rule matching.

[0096] Step 602: If any of the following termination rules are met, set stop_flag = true and record the termination reason, as shown in the table below: For example, given the status combination of `lifecycle_status = number retention period AND public_network_switch = on`, the public network switch should normally be off during the number retention period. This combination indicates a potential inconsistency in the operator's configuration, and none of the above termination rules apply. At this point, the system proceeds to step 603 to continue the next stage of verifying the real-name authentication status and the operator's backend configuration. The `reason_trace` field in the stage status memory is marked with "The number retention period and public network switch status are inconsistent; it is recommended to check the operator's backend," for LLM's subsequent stage planning reference.

[0097] Step 603: If no termination rule is hit, and there are unqueried key items in the current stage memory, the Agent planning module increments the current stage number in the task context layer by 1 (e.g., phase_1 increments to phase_2), generates the next stage diagnostic plan, and re-enters step S3 to start the next diagnostic stage. Note: From the second stage onwards, the Agent planning module uses a continuation stage planning template (instead of the initial template for the first stage). Its input context adds the state memory chain of completed stages to the original hierarchical context, allowing LLM to continue planning based on the reasoning conclusions of previous stages, instead of starting from scratch to understand the task again. To prevent infinite loops in abnormal situations, the system sets the maximum number of diagnostic stages to 4 stages (including the first stage); if no termination rule is hit when the iteration rounds reach the upper limit, the loop is forcibly exited, and step 604 is executed directly.

[0098] Step 604: If all preset diagnostic stages have been completed (or the maximum number of stages has been reached) but the termination rule has not been hit, then set stop_flag to true, set the diagnostic conclusion to "failed to locate the clear cause, manual intervention is recommended", and trigger the work order escalation process; then proceed to step S7 to execute diagnostic link recording and context release, and then proceed to step S8 to generate a structured diagnostic report containing manual intervention instructions.

[0099] Step S7: Perform context-based clipping. This includes the following steps: Step 701: When the termination determination module sets stop_flag to true (including two cases: early termination due to rule hit and reaching the maximum stage limit), the system immediately terminates the subsequent tool call process.

[0100] Step 702: The system no longer loads the context of the following unexecuted phases: dynamic state context fields of untriggered phases, tool call parameter templates corresponding to the phase, access credentials and call configurations of related interfaces.

[0101] Step 703: Record the actual length of the diagnostic link (number of tools executed) into the final state memory as a diagnostic efficiency indicator.

[0102] Step 704: The context pruning mechanism ensures that the number of input tokens during large model inference does not exceed the actual needs of the current stage, avoiding redundant context from causing a decrease in inference quality or an overspending of token costs.

[0103] Step S8: Generate the final diagnostic report. This includes the following steps: Step 801: The result generation module takes the final stage state memory chain and conclusion label as input to generate a structured diagnostic report.

[0104] Step 802, the diagnostic report includes the following field template: { "task_id": "DIAG-2025-001", "sim_id": "8966XXXXXXXXXXXX", "vehicle_id": "VIN-XXXXXXX", "diagnosis_time": "2025-08-26T11:19:21+08:00", "lifecycle_status": "Number retention period", "public_network_switch": "Off", "realname_auth_status": "Not queried", "traffic_status": "Not queried", "dial_record": "Not queried", "queried_phases": ["phase_1"], "total_tool_calls": 2, "problem_nature": "Normal phenomenon", "root_cause": "The SIM card is currently in the number retention period, and the operator platform has automatically disabled public network access. The in-vehicle infotainment system having no network connection is normal." "is_fault": false, "handling_suggestion": "It is recommended that the vehicle owner renew their service as soon as possible. The network will be automatically restored after successful renewal, with an estimated restoration time of approximately 15 minutes." "next_action": "notify_customer_to_renew", "escalation_required": false, "report_for_customer": "Your vehicle infotainment SIM card has entered the number preservation period. Network service has been automatically suspended. Please renew your subscription and wait approximately 15 minutes for network access to be automatically restored." "report_for_cs": "During the SIM card's number retention period, the public network switch has been turned off. This is a normal network outage scenario and does not require reporting a fault. Simply guide the customer to renew their subscription." "report_for_ops": "Rule R-001a was hit, lifecycle = account retention period, public network switch = off, diagnosis has been terminated early, no further investigation is needed." } Step 803: The diagnostic report automatically selects the output layer (owner version, customer service version, maintenance version) based on the request source, and differentiates the language style and information depth.

[0105] Step 804: If the diagnostic conclusion is platform-manageable (e.g., "renewal and reactivation" or "enabling public network access"), the system can choose to call the corresponding handling tool to automatically complete the operation. The calling of the handling tool is an extension of the tool calling module in step S4 and shares the calling record mechanism with the diagnostic query tool. After the handling is completed, the handling type, execution time, and result are added to the diagnostic report as supplementary fields, and step S9 is triggered simultaneously to include the handling action and result in the historical memory. If the handling fails, the system records the reason for the failure in the handling_result field of the report and sets the escalation_required flag to true, triggering the manual takeover process.

[0106] Step S9: Preserving historical memory. This includes the following steps: Step 901: After the current task diagnosis is completed, the historical memory accumulation module writes the following content into the historical memory bank: basic task information (task ID, SIM card number, vehicle ID, trigger time), status memory chain of each stage, final diagnosis conclusion and conclusion label, actual tool call order, diagnosis chain length (number of stages, number of tool calls), termination rule hit status, and handling result (if automatic handling has been performed, record the handling type and result).

[0107] Step 902: Historical memories are indexed by sim_id and vehicle_id to support rapid retrieval of similar historical issues.

[0108] Step S10: Subsequent reuse loop closure. This specifically includes the following steps: Step 1001: When the system receives a new SIM network diagnostic task, the historical memory retrieval module uses the current sim_id, vehicle_id, and problem_description as search criteria to retrieve the most similar historical diagnostic record from the historical memory database. This step performs deep path retrieval, completely extracting the state memory chain and tool call order of each stage of the historical task to guide the stage planning of the current task; it complements the shallow historical summary loaded in step S2—S2 provides a quick background understanding, while S10 provides a reusable complete diagnostic path. The two have different data granularities and call timings, and their functions do not overlap.

[0109] Step 1002, similarity calculation comprehensively considers the following dimensions: SIM card number matching degree (same card preferred), vehicle ID matching degree, problem tag similarity, and historical termination rule hit rate.

[0110] Step 1003: When a highly similar historical record is retrieved, if the rule version consistency check passes, the Agent planning module will prioritize the diagnostic path of that historical record, shorten the number of stages, adjust the tool call order, and improve the first-time resolution rate.

[0111] Step 1004: Through continuous accumulation, historical memory gradually improves the rule blind spots, assists operation and maintenance personnel in discovering recurring fault patterns, and provides data basis for the iterative update of the rule set.

[0112] The above steps S1 to S10 form a complete logical closed loop. The diagnostic results of a single task continuously feed back into the overall system capabilities, enabling the intelligent diagnostic agent to evolve itself.

[0113] Figure 6 This is an architecture diagram of the vehicle network diagnostic system provided in the embodiments of this application. Figure 3 The system consists of the following eight core modules: Task access module: Standardizes multi-source diagnostic requests into task objects. It is mainly used to receive network diagnostic requests and parse them into task objects.

[0114] The hierarchical context building module organizes the diagnostic context into a four-layer structure. It is primarily used to construct a four-layer context object based on the task object. This four-layer context object is obtained by merging the global context layer, task context layer, dynamic state context layer, and rule context layer.

[0115] The Agent Reasoning and Planning module combines rules and a large model for phased planning. It primarily works by linking the rule engine and the large language model to generate a diagnostic execution plan for the current phase based on the four-layer context objects.

[0116] Tool Invocation Module: Interacts with the business system interface to complete the actual query. It is mainly used to invoke tools as needed to query network conditions and generate query results for the current stage, based on the current stage's diagnostic execution plan; the on-demand invocation of the business interface refers to invoking only the tools listed in the current stage's diagnostic execution plan.

[0117] Stage State Memory Module: Compresses stage results into structured memory. It is primarily used to compress the query results of the current stage to generate the stage state memory of the current stage, and then appends the stage state memory of the current stage to the stage state memory chain of the current stage.

[0118] Termination Decision Module: Determines whether to terminate prematurely based on rules and memory. It primarily loads the current stage's state memory and matches it against a preset termination rule set. If the matching result meets preset conditions, the network diagnostics terminates. If the matching result does not meet preset conditions, the rule engine and large language model are re-linked, and a diagnostic execution plan for the next stage is generated based on the four-layer context object, and the next stage of network diagnostics is performed.

[0119] Result Generation Module: Generates diagnostic reports for multiple roles. It is primarily used to generate network diagnostic reports based on the stage state memory chain and diagnostic conclusion tags of the final stage.

[0120] Historical Memory Accumulation Module: This module writes diagnostic experience into a reusable memory bank. It primarily stores the task object, the memory chain of stage states for each stage, diagnostic conclusions, diagnostic conclusion tags, the actual tool call order, diagnostic link length, and termination rule hit status into the historical memory bank; and establishes a retrieval index for the historical memory bank along with SIM identifiers, vehicle identifiers, and fault descriptions.

[0121] The above embodiments also have the following alternative and extended solutions, as detailed below: 1. Replacement and expansion of tool calling modules The query interface in the tool invocation module is adaptable to the API specifications of different operators or vehicle networking platforms. It can be a RESTful HTTP interface, or it can be a gRPC call, message queue consumption, etc. The tool list itself supports plug-in expansion. To add a diagnostic dimension, you only need to register the corresponding tool description and invocation specification, without modifying the Agent planning logic.

[0122] 2. Replacement of the large language model The large language model in the Agent reasoning and planning module can be replaced with LLMs from different vendors or of different sizes, such as GPT-4o, Claude 3.5, Qwen2.5, DeepSeek, etc., or a locally deployed private model can be used. The rule engine always serves as a hard constraint fallback, ensuring that the system can still rely on rules to guarantee basic diagnostic capabilities when the availability of the LLM decreases.

[0123] 3. Extension of hierarchical context The global context layer in the hierarchical context structure can be expanded to include more dimensions, such as vehicle OTA upgrade records, recent firmware version changes, and regional network quality indicators, to support comprehensive analysis of more complex scenarios. The task context layer can access multimodal information, such as signal strength logs reported by the vehicle's infotainment system and network jitter sampling data, to further improve diagnostic accuracy.

[0124] 4. Application Scenarios Expansion This solution is not limited to SIM network diagnostic scenarios. Its core methodology of "layered context management + stage state memory + rule and LLM collaboration + dynamic link pruning" can be extended to: (1) In-vehicle OTA upgrade fault diagnosis: Automatic analysis of the reasons for OTA task failure in stages; (2) Diagnosis of abnormal binding / unbinding of vehicle-mounted devices: Intelligent investigation of abnormal binding status of vehicle-mounted devices and account association; (3) Fault diagnosis of energy supply system (new energy vehicles): Automatically locate problems such as abnormal communication of charging piles and charging interruption; (4) Enterprise IT network equipment fault diagnosis: Apply the same architecture to the operation and maintenance scenarios of network equipment such as enterprise intranet switches and routers; (5) Industrial Internet of Things (IoT) device status diagnosis: Perform multi-stage intelligent diagnosis for scenarios such as sensor node offline and data anomalies.

[0125] 5. Expansion of Stage State Memory Format The confidence_score in the stage state memory field can introduce a dynamic confidence calculation mechanism based on Bayesian updates. As the query results of each stage accumulate, the probability weight of each possible cause is automatically adjusted to help the agent make better planning decisions for the next step in uncertain scenarios.

[0126] 6. Integration with ITSM work order system The diagnostic report generation module can be directly integrated with the enterprise's existing ITSM (IT Service Management) ticketing system. It supports the automatic creation of ticketing systems, filling in diagnostic conclusions, assigning handlers or processing queues after the diagnosis is completed, and automatically closing the ticketing system or updating the ticketing status after automatic handling is completed, thus achieving an end-to-end closed-loop handling process without human intervention.

[0127] 7. Historical Memory Lifecycle Management The historical memory repository offers configurable lifecycle policies: for historical memory entries exceeding 180 days, the system automatically performs archiving, retaining core fields such as basic task information, final diagnostic conclusions, and termination rule hit tags, while releasing detailed stage state memories to control storage costs during long-term operation. Archiving policies can be configured with retention periods by operator, vehicle model, or business segment, and can be adjusted as needed.

[0128] The embodiments described above in this application achieve the following technical effects and advantages through hierarchical context management, stage state memory, rule-based and large-model collaborative reasoning, dynamic pruning and diagnostic links, and historical memory reuse closed loop: 1. Reduce invalid tool calls and improve diagnostic response efficiency.

[0129] The embodiments described above employ a hierarchical context management and phase planning mechanism. This means that in each diagnostic phase, the system only loads and calls the context information and tool interfaces truly needed for that phase, rather than executing the full query chain in a fixed order. Because if a termination rule is hit in an early phase, subsequent tool calls will be completely skipped. Therefore, for high-frequency deterministic scenarios such as network outages during number retention periods or service interruptions due to unpaid fees (which constitute a major proportion of SIM fault tickets in the vehicle networking industry), the number of interface calls can be reduced by 60% to 80%, requiring only 2 interface calls to complete the diagnosis, whereas existing fixed chains require 5 to 8 calls. For complex scenarios requiring a complete troubleshooting chain (such as the R-006 fallback rule scenario), redundant queries can still be avoided due to the priority optimization of the tool call order. This solves the problem of existing fixed query chains being unable to terminate early and the waste of interface resources, reducing system operating costs and shortening diagnostic response time.

[0130] 2. Improve coverage of complex scenarios and reduce the false negative rate.

[0131] The embodiments described above employ a collaborative planning mechanism between a rule engine and a large language model. This means that rules ensure deterministic judgments for clearly defined state combinations, while the LLM (Large Language Model) handles complex scenarios and multi-factor situations not covered by the rules. Because the LLM possesses the ability to comprehensively reason about multi-dimensional state information, it can handle boundary cases that are difficult for rule systems to exhaustively enumerate. Therefore, the diagnostic coverage and accuracy of complex symptoms are significantly improved compared to pure rule systems. This solves the problem that existing rule engines can only handle predefined scenarios and have high false negative rates in complex situations.

[0132] 3. Reduce context redundancy in large model inference and lower token costs.

[0133] The embodiments described above employ a stage-state memory mechanism. This means that the original query results of each stage are compressed into structured summary fields instead of retaining the full original data. Subsequent LLM inference stages directly consume the compressed memory instead of the complete original input. Because the information density of the structured summary is much higher than the original API response, the memory volume of a single stage is typically less than 500 bytes. Therefore, the number of context input tokens for LLM inference is reduced by more than 85% compared to the full input method. Simultaneously, the stage-state memory is transferred between stages in a structured manner. Agent planning in subsequent stages can directly continue based on the inference conclusions of previous stages without re-parsing the original data, achieving cross-stage continuous inference. This solves the problems of inference focus loss and cost overruns caused by full context in existing large model integration schemes, as well as the lack of a structured state transfer mechanism between stages in existing systems, which prevents them from supporting cross-stage continuous inference.

[0134] 4. Improve the interpretability of diagnostic results and empower multi-role collaboration.

[0135] The embodiments described above employ a multi-role structured report generation mechanism. This means the system generates differentiated diagnostic reports for vehicle owners, customer service personnel, and maintenance staff based on the final stage state memory chain. These reports include root cause explanations, handling suggestions, and process summaries. Because the required information depth and language style differ significantly between roles, the structured, layered output accurately matches the needs of each role, thus improving problem-solving efficiency and the one-time work order resolution rate. This solves the problem of existing systems only outputting binary conclusions, requiring downstream handling to rely on manual re-judgment.

[0136] 5. Establish a closed loop for experience accumulation and continuously optimize diagnostic capabilities.

[0137] The embodiments described above employ a historical memory accumulation and reuse mechanism. This means that after each diagnostic task is completed, the diagnostic path, state memory, and conclusion are accumulated in a historical memory bank. Subsequent similar tasks prioritize reusing the historical path. Because historical memory continuously enriches with task accumulation, the system's ability to identify and process high-frequency scenarios continuously improves. Therefore, as the system's runtime increases, the initial hit rate and first-time resolution rate continuously improve. This solves the problem of existing systems "starting from scratch with each diagnosis, lacking experience accumulation," and achieves a continuously optimized intelligent diagnostic closed loop.

[0138] The systems, devices, and methods disclosed in the several embodiments provided in this application can also be implemented in other ways. The system, device, and method embodiments described above are merely illustrative. For example, the flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of apparatus, methods, and computer program products according to various embodiments of this application. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code, 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 marked 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 a block diagram and / or flowchart, and combinations of blocks in block diagrams and / or flowcharts, can 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.

[0139] In addition, the functional modules in the various embodiments of this application can be integrated together to form an independent part, or each module can exist independently, or two or more modules can be integrated to form an independent part.

[0140] If a function is implemented as a software module and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or a portion of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods of the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as a USB flash drive, a portable hard drive, a read-only memory (ROM), a random access memory (RAM), a magnetic disk, or an optical disk.

Claims

1. A method for diagnosing vehicle-to-everything (V2X) networks, characterized in that, Includes the following steps: Receive network diagnostic requests and parse the network diagnostic requests into task objects; Based on the task object, a four-layer context object is constructed, which is obtained by merging the global context layer, the task context layer, the dynamic state context layer, and the rule context layer. The linkage rule engine and large language model generate a diagnostic execution plan for the current stage based on the four-layer context objects; Based on the current stage's diagnostic execution plan, tools are invoked as needed to query network conditions and generate query results for the current stage; the on-demand invocation of the business interface only invokes the tools listed in the current stage's diagnostic execution plan. The query results of the current stage are compressed to generate the stage state memory of the current stage, and the stage state memory of the current stage is appended to the stage state memory chain of the current stage. The current stage's state memory is loaded and matched with a preset set of termination rules. If the matching result meets the preset conditions, the network diagnosis is terminated and a network diagnosis report is generated.

2. The vehicle network diagnostic method according to claim 1, characterized in that, If the matching result does not meet the preset conditions, the rule engine and the large language model will be re-linked to generate the next stage of the diagnostic execution plan based on the four-layer context object, and the next stage of network diagnosis will be performed.

3. The vehicle network diagnostic method according to claim 2, characterized in that, The generation of the next-stage diagnostic execution plan based on the four-layer context objects includes: Based on the four-layer context objects and the stage state memory chain of the executed stage, a diagnostic execution plan for the next stage is generated.

4. The vehicle network diagnostic method according to claim 1, characterized in that, The matching result meets the preset conditions, including: the matching result is a match for any termination rule, or the matching result is a completion of all diagnostic stages but no termination rule is matched, or the matching result is the maximum number of diagnostic stages reached but no termination rule is matched.

5. The vehicle network diagnostic method according to claim 1, characterized in that, Before generating the network diagnostic report, the following is also included: Execution context pruning discards all context data from unexecuted phases. Record the length of the diagnostic link of the executed stage into the stage state memory chain of the final stage.

6. The vehicle network diagnostic method according to claim 5, characterized in that, The generated network diagnostic report includes: Based on the stage state memory chain and diagnostic conclusion labels of the final stage, a network diagnostic report is generated.

7. The vehicle network diagnostic method according to claim 1, characterized in that, The task objects include SIM identifier, vehicle identifier, and fault description.

8. The vehicle network diagnostic method according to claim 7, characterized in that, Following the generation of the network diagnostic report, the following is also included: The task object, the stage state memory chain of each stage, the diagnostic conclusion, the diagnostic conclusion label, the actual tool call order, the diagnostic link length, and the termination rule hit status are stored in the historical memory bank. Establish a retrieval index for the historical record database along with SIM identifiers, vehicle identifiers, and fault descriptions.

9. The vehicle network diagnostic method according to claim 8, characterized in that, Following the generation of the network diagnostic report, the following is also included: When a new diagnostic request is received, the historical memory is retrieved based on the SIM identifier, vehicle identifier, and fault description, and a historical diagnostic path with a similarity exceeding a preset similarity threshold is selected. Based on the historical diagnostic path, a diagnostic execution plan corresponding to the new diagnostic request is generated.

10. An electronic device, characterized in that, The electronic device includes: processor; Memory used to store processor-executable instructions; The processor is configured to execute the vehicle network diagnostic method according to any one of claims 1-9.

Images