Vehicle diagnosis service method and system based on dynamic protocol adaptation and context awareness

Abstract

The invention discloses a vehicle diagnosis service method and system based on dynamic protocol adaptation and context awareness, and the method comprises the steps: analyzing a diagnosis request, and determining a service range and a dependency relationship required by the diagnosis request; obtaining multi-dimensional context information, and based on the obtained information and the dependency relationship, executing a routing decision to select an optimal service instance and a protocol path; dynamically calling a protocol adapter through a protocol adaptation matrix based on the service instance and the protocol path, converting the diagnosis request into a protocol message, and sending the protocol message to a vehicle network; and receiving the original diagnosis data returned by the vehicle network to generate a complete diagnosis report. According to the method, flexible calling of the protocol adapter is realized through the dynamic protocol adaptation matrix, the service range and the dependency relationship are analyzed in combination with the service governance engine, and the routing decision is optimized by utilizing the multi-dimensional context information, so that the method has the advantages of dynamic and flexible protocol adaptation, accurate and intelligent service analysis and global optimization of the routing decision.

Description

Technical Field

[0001] This invention belongs to the field of vehicle diagnostic technology, specifically relating to a vehicle diagnostic service method and system based on dynamic protocol adaptation and context awareness. Background Technology

[0002] Vehicle diagnostics, as a core component of modern automotive repair, maintenance, and R&D, has seen a significant increase in the number and types of onboard electronic control units (ECUs) due to the continuous evolution of automotive electronic architecture. This has led to a highly diversified landscape of vehicle communication protocols, including CAN, LIN, FlexRay, K-Line, and DoIP. Existing diagnostic systems have revealed deep-seated technical bottlenecks when dealing with complex scenarios involving multiple protocols.

[0003] At the protocol adaptation level, traditional solutions rely on layered or stacked static protocol stacks. Protocol switching and adaptation strictly follow pre-configuration rules, which cannot achieve dynamic discovery and hot-swapping capabilities of protocol adapters. When new or non-standard protocols are introduced, system-level upgrades or recompilation are required, resulting in a rigid adaptation process, a serious lack of flexibility, and high maintenance costs.

[0004] At the service management level, the existing mechanism only uses a basic service registry to record service addresses and interface information, lacking semantic descriptions of service capabilities, such as functional scope, input and output parameters and preconditions, and is unable to express the dependencies and composition logic between services. This results in weak service discovery capabilities and makes it difficult to support intelligent composition and on-demand scheduling of services.

[0005] At the routing decision level, path selection for diagnostic requests is usually limited to fixed rules (such as matching protocols based on vehicle identification numbers) or single technical indicators (such as network connectivity). It fails to integrate multi-dimensional contextual information such as real-time vehicle status (such as electronic control unit load and network latency), system resource status (such as diagnostic server computing and memory usage), and business strategy requirements (such as service priority and cost constraints). This results in a lack of global optimization capabilities for path selection and an inability to adapt to dynamic changes in the in-vehicle environment.

[0006] The aforementioned problems collectively restrict the real-time performance, flexibility, and reliability of vehicle diagnostic systems, and urgently require breakthroughs through innovative technical solutions. Summary of the Invention

[0007] The purpose of this invention is to address the shortcomings of the aforementioned background technology and provide a vehicle diagnostic service method and system based on dynamic protocol adaptation and context awareness, which has the advantages of dynamic and flexible protocol adaptation, accurate and intelligent service parsing, and global optimization of routing decisions.

[0008] The technical solution adopted in this invention is: a vehicle diagnostic service method based on dynamic protocol adaptation and context awareness, comprising the following steps: The diagnostic request is parsed to determine the service scope and dependencies required by the diagnostic request. Obtain multi-dimensional context information, and based on the obtained information and the aforementioned dependencies, perform routing decisions to select the optimal service instance and protocol path; Based on the service instance and protocol path, the protocol adapter is dynamically invoked through the protocol adaptation matrix to convert the diagnostic request into a protocol message and send it to the vehicle network; Receive raw diagnostic data returned from the vehicle network to generate a complete diagnostic report.

[0009] Furthermore, the diagnostic requests are parsed through a service governance engine, which embeds a diagnostic service capability graph. The diagnostic service capability graph is a knowledge base that stores semantic descriptions of diagnostic services, dependencies, and compositional logic. The service governance engine uses the diagnostic service capability graph to perform service parsing and matching on diagnostic requests to determine the required service scope and dependencies.

[0010] Furthermore, by connecting vehicle status sensors, system resource monitors, and business policy libraries through a context-aware router, multi-dimensional contextual information including vehicle status, system resources, and business policies can be obtained.

[0011] Furthermore, the step of performing routing decisions and selecting the optimal service instance and protocol path based on the acquired information and the dependencies includes: Context-aware routers perform constraint filtering on all candidate service instances based on service dependencies, excluding service instances that do not meet the dependency requirements. A weighted scoring algorithm is used to score the remaining candidate service instances from three aspects: vehicle adaptability, resource availability, and policy matching degree. The service instance with the highest score and its corresponding protocol path are selected as the optimal route. The weighted scoring algorithm is implemented based on technical indicators, business indicators, economic indicators, and configurable weights.

[0012] Furthermore, the step of dynamically invoking the protocol adapter through the protocol adaptation matrix to convert the diagnostic request into a protocol message and send it to the vehicle network includes: The protocol adaptation matrix selects a protocol adapter corresponding to the protocol path from the adapter pool, and encapsulates the diagnostic request into a protocol message that conforms to the vehicle communication protocol standard and sends it to the vehicle network through the selected protocol adapter. The protocol adaptation matrix internally encapsulates a protocol feature description library and a protocol conversion mapping rule library, and is capable of receiving registration information from different protocol adapters.

[0013] Furthermore, after selecting the optimal service instance and protocol path, a context container for the diagnostic session is created and managed through the session manager. The context container is a lightweight data structure used to store incremental state changes of the diagnostic session, and the state is saved and restored through persistent storage of session state.

[0014] Furthermore, it also includes: The diagnostic requests are formatted and validated using a data conversion pipeline; the processed data is then sent to the vehicle network as protocol messages via a protocol adapter. The data conversion pipeline performs protocol unpacking, format conversion, and legality verification on the raw diagnostic data returned by the vehicle network to generate standardized diagnostic results. A complete diagnostic report is generated from standardized diagnostic results through the service instance layer.

[0015] Furthermore, the data conversion pipeline consists of several pluggable modular conversion components. The pipeline assembler dynamically combines these modular conversion components into a processing chain based on the data characteristics to process the flowing data.

[0016] Furthermore, it also includes an intelligent resource scheduler with a built-in predictive model that continuously monitors historical load data, predicts resource demand based on historical load data, and issues dynamic scaling and load migration instructions to the service instance layer.

[0017] Furthermore, it also includes releasing session resources after the diagnostic task is completed or fails, including disconnecting the protocol adapter association and cleaning up persistent state, updating the system resource state table, and marking the adapter as idle.

[0018] A system for implementing the vehicle diagnostic service method based on dynamic protocol adaptation and context awareness as described above includes: The service governance engine is used to parse diagnostic requests and determine the service scope and dependencies required by the diagnostic requests. A context-aware router is used to acquire multi-dimensional context information and, based on the acquired information and the dependencies, to perform routing decisions and select the optimal service instance and protocol path. A protocol adaptation matrix is ​​used to dynamically invoke the protocol adapter based on the service instance and protocol path. A protocol adapter is used to convert the diagnostic request into a protocol message and send it to the vehicle network, and to receive the raw diagnostic data returned by the vehicle network.

[0019] The beneficial effects of this invention are as follows: This invention enables flexible invocation of protocol adapters through a dynamic protocol adaptation matrix, combines a service governance engine to parse service scope and dependencies, and optimizes routing decisions using multi-dimensional contextual information. It solves the problems of rigid protocol adaptation, lack of semantic description in service management, and lack of global optimization in routing decisions in existing technologies. It has the advantages of dynamic and flexible protocol adaptation, accurate and intelligent service parsing, and global optimization of routing decisions.

[0020] This invention offers exceptional flexibility: through its matrix-style parallel adapter structure and hot-swappable mechanism, it enables seamless integration of new protocols without requiring downtime for upgrades.

[0021] This invention boasts an exceptional level of intelligence: based on a semantic service capability graph and multi-dimensional context-aware routing, the system is capable of in-depth service discovery and optimal path decision-making, improving the accuracy and efficiency of diagnosis.

[0022] This invention has strong robustness: incremental session management and breakpoint resume mechanism ensure the reliability of complex diagnostic processes and can be completed smoothly even in unstable network environments.

[0023] This invention features highly efficient data processing: the adaptive data transformation pipeline avoids unnecessary data processing overhead and improves system throughput.

[0024] This invention features optimized resource utilization: predictive intelligent resource scheduling enables on-demand allocation of resources, reducing operating costs while ensuring service quality. Attached Figure Description

[0025] Figure 1 This is a flowchart of the vehicle diagnostic service method of the present invention.

[0026] Figure 2 This is a schematic diagram of the vehicle diagnostic service system of the present invention. Detailed Implementation

[0027] In the following description, specific details such as particular system architectures and techniques are set forth for illustrative purposes and not for limitation, in order to provide a thorough understanding of the embodiments of the invention. However, those skilled in the art will understand that the invention can be implemented in other embodiments without these specific details. In other instances, detailed descriptions of well-known systems, apparatuses, circuits, and methods are omitted so as not to obscure the description of the invention with unnecessary detail.

[0028] It should be understood that, when used in this specification and the appended claims, the term "comprising" indicates the presence of the described features, integrals, steps, operations, elements and / or components, but does not exclude the presence or addition of one or more other features, integrals, steps, operations, elements, components and / or collections thereof.

[0029] like Figure 1 As shown in the figure, this application proposes a vehicle diagnostic service method based on dynamic protocol adaptation and context awareness, including the following steps: The diagnostic request is parsed to determine the service scope and dependencies required for the diagnostic request. Obtain multi-dimensional context information, and based on the obtained information and dependencies, perform routing decisions to select the optimal service instance and protocol path; Based on service instances and protocol paths, the protocol adapter is dynamically invoked through the protocol adaptation matrix to convert diagnostic requests into protocol messages and send them to the vehicle network. Receive raw diagnostic data returned from the vehicle network to generate a complete diagnostic report.

[0030] The parsing of diagnostic requests can be understood as the process of decomposing diagnostic requirements, with the aim of clarifying the functional modules involved in the diagnostic task and their interrelationships. Specifically, the required service scope can be identified by analyzing keywords or parameters in the diagnostic request, such as matching the corresponding set of service functions based on specific identifiers contained in the request. Furthermore, the determination of dependencies can be achieved using graph structure modeling, such as constructing a directed acyclic graph to represent the call order and constraints between services.

[0031] In practical applications, acquiring multi-dimensional contextual information can be achieved in various ways. For example, vehicle operating status data can be collected in real time from the vehicle sensor network, or current resource usage can be extracted through the system monitoring interface. Furthermore, business policy information can be read from a predefined rule base. The comprehensive processing of this information provides fundamental support for subsequent routing decisions. The dynamic invocation mechanism of the protocol adaptation matrix can be implemented using a plug-in architecture. Specifically, protocol adapters can be designed as independent executable modules, storing their functional descriptions in the adaptation matrix through a registration mechanism. When protocol conversion is required, the adaptation matrix selects and invokes a suitable instance from the registered adapters based on the characteristics of the target protocol.

[0032] This application achieves dynamic expansion of protocol conversion capabilities through a protocol adaptation matrix, avoiding system reconstruction issues caused by protocol updates. Simultaneously, by comprehensively evaluating multi-dimensional contextual information, it overcomes the limitations of traditional routing decisions relying solely on a single technical indicator, thereby improving the flexibility and adaptability of the diagnostic service. Furthermore, the explicit definition of service scope and dependencies during diagnostic request parsing provides necessary semantic support for the execution of complex diagnostic tasks.

[0033] The working principle of this embodiment is as follows: First, the diagnostic request is parsed to clarify its required service scope and dependencies. This process clarifies the functional boundaries and interdependencies of services through semantic description, laying the foundation for subsequent intelligent decision-making. Further, multi-dimensional contextual information is acquired and used for routing decisions. Real-time data such as vehicle status, system resources, and business strategies are comprehensively evaluated, and candidate service instances are screened based on service dependencies to select the optimal service instance and protocol path. Specifically, the context-aware mechanism ensures that routing decisions are no longer limited to a single technical dimension but can dynamically adapt to the complex and ever-changing in-vehicle environment. Based on this, the protocol adaptation matrix dynamically calls the corresponding protocol adapter according to the selected service instance and protocol path, encapsulating the diagnostic request into a protocol message conforming to the vehicle communication protocol standard and sending it to the vehicle network. This achieves flexibility and dynamism in protocol adaptation, avoiding the upgrade dependency problem of static protocol stacks. Finally, the raw diagnostic data returned by the vehicle network is received and a complete diagnostic report is generated, ensuring the closed-loop completion of the diagnostic process. The aforementioned technical features work together to provide a basis for routing decisions through request parsing. Multi-dimensional contextual information and dependencies jointly drive route selection. The protocol adaptation matrix dynamically calls the adapter based on the selected path to achieve protocol conversion, ultimately forming an end-to-end intelligent diagnostic chain from request to report. This effectively solves the problems of rigid protocol adaptation, insufficient service dependency management, and single routing decision.

[0034] In one embodiment, this application further proposes parsing diagnostic requests through a service governance engine. The service governance engine embeds a diagnostic service capability graph, which is a knowledge base storing semantic descriptions, dependencies, and compositional logic of diagnostic services. The service governance engine performs service parsing and matching on the diagnostic request based on the diagnostic service capability graph to determine the required service scope and dependencies.

[0035] Specifically, a service governance engine is a software component used to manage and coordinate diagnostic services. It can be implemented using service mesh technology in a microservice architecture or a rule-based parsing framework, aiming to improve the intelligence level of diagnostic request parsing. A diagnostic service capability graph can be understood as a structured knowledge base, built using graph databases or semantic web technologies. It aims to store the functional scope, input and output parameters, preconditions, and dependencies and compositional logic between services. This graph design upgrades service information from traditional flat records to a model with rich semantic features, thereby supporting more accurate service parsing and matching.

[0036] In detail, the service governance engine achieves intelligent parsing and matching of diagnostic requests through an embedded diagnostic service capability graph. In actual operation, when a diagnostic request arrives, the service governance engine first extracts key information from the request and compares it with the semantic description in the diagnostic service capability graph. This process considers not only the basic interface information of the service but also the service's functional scope, dependencies, and compositional logic, thereby ensuring the accuracy of the parsing results. For example, when faced with complex multi-step diagnostic tasks, the service governance engine can dynamically filter out service instances that meet the requirements based on the dependencies in the graph and determine their execution order. Furthermore, the introduction of the diagnostic service capability graph enables the system to adapt to the dynamic adaptation needs of new or non-standard protocols, avoiding the limitations of traditional static rules. In this way, the service governance engine significantly improves the efficiency and reliability of diagnostic services while providing accurate input for subsequent routing decisions.

[0037] The above solution, through deep integration of the service governance engine and the diagnostic service capability graph, upgrades the flat service registry containing only address information into a dynamic knowledge graph rich in semantics. It establishes dependencies and composition rules between services, supports version management and learning evolution of capabilities, realizes intelligent discovery, composition and recommendation of services, improves the intelligence level and service reuse capability of the diagnostic system, and enables the diagnostic system to adapt to complex and ever-changing vehicle service needs.

[0038] In one embodiment, this application further proposes to connect a vehicle status sensor (collecting network latency, ECU online status, etc.), a system resource monitor (collecting CPU, memory usage, etc.), and a business policy library (storing SLAs, priority rules, etc.) through a context-aware router to obtain multi-dimensional context information including vehicle status, system resources, and business policies.

[0039] Specifically, a context-aware router is a middleware component capable of dynamically capturing and integrating heterogeneous data from multiple sources. It can be implemented using an event-driven architecture-based data acquisition module or distributed message queue technology, aiming to acquire multi-dimensional information such as vehicle operating status, system resource usage, and business policy constraints in real time. A vehicle status sensor is a hardware device or software module capable of monitoring real-time vehicle operating parameters. It can be implemented by directly reading ECU data through the vehicle bus interface or by collecting vehicle operating condition information using a telematics unit, aiming to provide an accurate description of the vehicle's current operating status. A system resource monitor is a monitoring tool used to track the resource usage within the diagnostic service system. It can be implemented using operating system-level performance counters or specially developed resource probes, aiming to ensure that routing decisions consider system load conditions. A business policy library is a knowledge base that stores and manages business rules related to the diagnostic service. It can be implemented through a rule engine or policy configuration files, aiming to introduce business-level constraints into routing decisions.

[0040] In detail, this solution achieves comprehensive acquisition of multi-dimensional contextual information by constructing a direct integration mechanism between a context-aware router and multi-source data. The context-aware router, as the core component, establishes connections with vehicle status sensors, system resource monitors, and a business policy library, forming a complete data acquisition network. When a diagnostic request arrives, the context-aware router first acquires real-time operational data from the vehicle status sensors, such as ECU load and network latency; simultaneously, it collects resource usage information, such as server CPU and memory usage, through the system resource monitor; and finally, it extracts business constraints, such as service priority and cost control, from the business policy library. This heterogeneous data, after integration, forms a comprehensive contextual view, providing comprehensive input for subsequent weighted scoring algorithms. In this process, by organically combining real-time vehicle status, system resource conditions, and business policy requirements, the adaptability and reliability of the diagnostic service are significantly improved.

[0041] Furthermore, this solution, combined with basic solutions such as diagnostic request parsing and service scope determination, provides more comprehensive support for routing decisions through the acquisition of multi-dimensional contextual information, making the selection of service instances and protocol paths more accurate and effectively addressing complex scenarios such as dynamic changes in vehicle networks, resource constraints, or adjustments in business needs.

[0042] In one embodiment, this application further proposes a specific implementation method for performing routing decisions and selecting the optimal service instance and protocol path based on the acquired information and dependencies. The context-aware router performs constraint screening on all candidate service instances based on service dependencies, excluding service instances that do not meet the dependency requirements; it employs a weighted scoring algorithm to score the remaining candidate service instances from three aspects: vehicle adaptability, resource idleness, and policy matching degree, selecting the service instance with the highest score and its corresponding protocol path as the optimal route; the weighted scoring algorithm is implemented based on technical indicators, business indicators, economic indicators, and configurable weights.

[0043] In practical applications, a context-aware router is a component capable of integrating multi-dimensional information and making intelligent decisions. It can be implemented using rule engines or machine learning models, aiming to reduce unnecessary computational overhead through hard filtering conditions based on dependencies. The weighted scoring algorithm is a dynamic quantitative fusion mechanism, which can be implemented based on linear weighted models or multi-objective optimization algorithms. Its purpose is to flexibly adjust the evaluation weights according to the actual scenario, thereby improving the adaptive capability of routing decisions. Specifically, vehicle adaptability refers to an indicator measuring the degree of matching between a service instance and the current vehicle operating conditions, which can be calculated by collecting real-time ECU load and network latency data; resource idleness is a quantitative indicator of system resource availability, which can be achieved by monitoring server CPU and memory usage; and policy matching degree is an evaluation standard for the degree of conformity between a service instance and business requirements, which can be modeled using priority and cost rules.

[0044] Specifically, this solution achieves dynamic optimization of diagnostic services through a multi-stage routing decision-making mechanism. First, the context-aware router uses service dependencies to initially screen candidate service instances, ensuring that only feasible options that meet basic functional logic are retained, thus significantly reducing the complexity of subsequent evaluations. Based on this, a weighted scoring algorithm comprehensively evaluates the remaining candidate service instances from three dimensions: vehicle suitability, resource availability, and policy matching. By incorporating technical, business, and economic indicators into a unified framework, it achieves dynamic fusion of multi-dimensional context. This process not only improves the comprehensiveness and flexibility of routing decisions but also allows for adjustments to weight configurations based on different scenario requirements. For example, in emergency diagnostic tasks, technical indicators are strengthened to ensure real-time performance, or in cost-sensitive scenarios, economic indicators are emphasized to optimize resource consumption. Furthermore, the above method, combined with the service dependencies parsed by the service governance engine, forms a complete decision-making chain from hard screening to soft evaluation, thereby achieving efficient and accurate routing selection in complex in-vehicle environments and fundamentally overcoming the suboptimal problems caused by the rigidity of traditional routing mechanisms.

[0045] Through the above technical solutions, the multi-dimensional context-aware intelligent routing decision model upgrades routing based on fixed rules or single technical indicators to a comprehensive weighted decision based on multi-dimensional contexts including technology, business, and economics. It uses configurable weight coefficients to quantitatively evaluate the comprehensive scores of different paths, achieving dynamic optimal path selection. In complex and ever-changing environments, it can always balance multiple factors such as latency, reliability, cost, and SLA to select the most suitable service instance and protocol path, ensuring service quality and cost-effectiveness.

[0046] In one embodiment, this application further proposes to dynamically invoke a protocol adapter through a protocol adaptation matrix to convert a diagnostic request into a protocol message and send it to the vehicle network. This includes: the protocol adaptation matrix selecting a protocol adapter corresponding to the protocol path from the adapter pool, and encapsulating the diagnostic request into a protocol message conforming to the vehicle communication protocol standard through the selected protocol adapter and sending it to the vehicle network; the protocol adaptation matrix internally encapsulates a protocol feature description library and a protocol conversion mapping rule library, and is able to receive registration information of different protocol adapters.

[0047] Specifically, a protocol adaptation matrix refers to a middleware component used for dynamically managing protocol adapters. It can be implemented using a modular design based on a plug-in architecture, aiming to support flexible access and dynamic switching of multiple protocol adapters. In practical applications, a protocol feature description library can be understood as a database storing semantic metadata of protocols. It can be organized using structured data formats such as JSON and XML, aiming to provide the system with the ability to automatically identify new protocols. Meanwhile, a protocol conversion mapping rule library is a set of rules storing dynamic conversion logic. It can be implemented using rule engine-based technology, aiming to ensure efficient conversion between different protocols.

[0048] In detail, this solution dynamically selects adapters based on the protocol paths determined during the routing decision phase using a protocol adaptation matrix, rather than relying on fixed mapping rules. This allows the selection process to be closely linked to the protocol requirements of the current diagnostic context, thereby automatically matching the real-time protocol characteristics of different vehicle networks. Furthermore, the protocol feature description library and protocol conversion mapping rule library encapsulated within the protocol adaptation matrix enable hot-swapping of adapters by receiving adapter registration information. This design not only avoids the limitations of pre-configuration but also significantly improves the system's adaptability to new or non-standard protocols. Building on this, the combined use of the protocol adaptation matrix and adapter pool further enhances the system's flexibility, enabling rapid response and completion of diagnostic tasks in the face of complex and ever-changing in-vehicle environments.

[0049] Through the above technical solutions, the matrix-style dynamic protocol adaptation mechanism innovates the traditional layered protocol stack model into a parallel matrix model. Each protocol adapter is registered in the adaptation matrix as an independent and equal node, rather than being hierarchically dependent. This enables hot-swapping of protocol adapters and dynamic discovery of capabilities. The system can integrate new protocols without downtime, effectively solving the problems of poor flexibility and high upgrade and maintenance costs caused by protocol rigidity in existing technologies. It achieves flexibility and scalability in protocol adaptation, while significantly improving the system's adaptability to protocol evolution and maintenance efficiency.

[0050] In one embodiment, this application further proposes, after selecting the optimal service instance and protocol path, to create and manage a context container for the diagnostic session through a session manager. The context container is a lightweight data structure used to store incremental state changes of the diagnostic session, and the state is saved and restored through persistent session state storage. The session manager will periodically or as needed persist the incremental state of the session container to ensure that execution can be resumed from the breakpoint in the event of an anomaly.

[0051] Specifically, a session manager is a logical component specifically designed to manage the lifecycle of diagnostic sessions. It can be implemented using a lightweight, memory-based framework or a distributed session management tool. Its purpose is to centrally manage the state information of diagnostic sessions, avoiding the resource waste associated with traditional full-state storage methods. The context container can be understood as a specially designed data structure. Its essence is a mechanism for storing incremental state changes within a diagnostic session, rather than saving a complete session snapshot, thus significantly reducing memory consumption. In practical applications, context containers can be implemented using linked lists, key-value pairs, or other efficient data organization methods to improve processing efficiency, especially suitable for resource-constrained scenarios in automotive environments. Furthermore, persistent session state storage is a technique for reliably writing incremental state changes to non-volatile storage media. It can be implemented using technologies such as databases, file systems, or distributed storage, aiming to quickly rebuild the session context in the event of network interruptions or service failures.

[0052] In detail, once the optimal service instance and protocol path are selected, the session manager immediately initiates the context container creation process for the diagnostic session. This container only records incremental state changes within the diagnostic session, such as updates to key parameters and caching of intermediate results, rather than storing all state information for the entire session. This design significantly reduces memory resource consumption while improving the flexibility of state management. During the diagnostic process, incremental state changes in the context container are periodically synchronized to persistent storage, ensuring that even in the event of network interruption or service anomalies, the session state can be quickly restored by reading data from persistent storage. This mechanism not only supports breakpoint resumption but also ensures the continuity of complex diagnostic processes, significantly improving the user experience. Furthermore, because the context container is lightweight and focuses on incremental state management, it can effectively adapt to the constraints of limited computing resources in the automotive environment, further optimizing the overall system performance.

[0053] Through the above technical solution, lightweight incremental diagnostic session management revolutionizes the traditional stateless request-response or full state synchronization mode into stateful incremental session management. By introducing a lightweight session context container and persistent storage, it supports partial updates of session state, serialization / deserialization, and breakpoint resumption, significantly reducing network overhead and server memory pressure in complex diagnostic processes. This greatly improves the robustness and user experience of long-process diagnostic tasks, achieving high efficiency and reliability in diagnostic services.

[0054] In one embodiment, this application further proposes: The diagnostic requests are formatted and validated using a data conversion pipeline. The processed data is then sent to the vehicle network as protocol messages via a protocol adapter. The data conversion pipeline performs protocol unpacking, format conversion, and legality verification on the raw diagnostic data returned by the vehicle network to generate standardized diagnostic results. A complete diagnostic report is generated from standardized diagnostic results through the service instance layer.

[0055] In practical applications, a data transformation pipeline refers to a modular, dynamically configurable data processing mechanism. It utilizes several pluggable modular transformation components dynamically combined into a processing chain based on data characteristics by a pipeline assembler, aiming to improve the system's adaptability to diverse data formats. Format conversion can be understood as adjusting input data to a standard form that conforms to the target protocol or processing requirements. This can be achieved through mapping tables, template engines, or scripting languages, ensuring data compatibility across different protocols. Legality verification refers to performing rule-based validation on data content to ensure it meets predefined constraints. This can be achieved through regular expression matching, syntax rule parsing, or business logic validation, aiming to reduce the risk of communication failures due to data errors. Standardized diagnostic results can be understood as structured and consistent output data after unified processing. This can be generated through data modeling tools or standardized interfaces, aiming to improve the usability and interoperability of diagnostic results.

[0056] Specifically, the data conversion pipeline performs format conversion and validity checks on diagnostic requests, ensuring that input data processing rules can be dynamically adjusted based on real-time data characteristics. This avoids the problem of traditional fixed pipelines being unable to adapt to new or non-standard data formats. The processed data is converted into protocol messages by a protocol adapter and sent to the vehicle network. This process is based on verified valid data transmission, significantly reducing the risk of communication failures caused by incorrect data formats or illegal content. For the raw diagnostic data returned from the vehicle network, the data conversion pipeline performs protocol unpacking, format conversion, and validity checks to generate standardized diagnostic results. This mechanism allows the system to dynamically select unpacking and conversion strategies based on the protocol characteristics of the returned data, overcoming the problem of insufficient parsing accuracy caused by rigid processing steps in traditional methods. Finally, the service instance layer generates a complete diagnostic report based on the standardized diagnostic results. A unified data standard ensures the structure and consistency of the report content, improving the usability of the diagnostic results. Overall, the modular design of the data conversion pipeline, combined with the protocol adaptation matrix and service governance engine in the above scheme, significantly enhances the system's adaptability to multi-protocol environments and variable data formats, and solves the technical problem that traditional fixed data processing pipelines lack adaptability and evolvability.

[0057] In one embodiment, this application further proposes a data conversion pipeline composed of several pluggable modular conversion components (such as data verification components, format conversion components, encryption components, etc.). The pipeline assembler dynamically combines the several modular conversion components into a processing chain according to the data characteristics to process the data flowing through it.

[0058] In practical applications, modular conversion components refer to decomposing diagnostic data processing functions into independent and replaceable functional units, which can be implemented using format conversion modules, validity verification modules, or protocol unpacking modules. The pipeline assembler can be understood as an intelligent orchestration tool that selects and arranges appropriate modular conversion components based on the specific attributes of the input data (such as protocol type, data format, or content characteristics), thereby forming a customized processing flow. The purpose of this design is to improve the flexibility and relevance of data processing, avoiding redundant steps or missing functions in traditional fixed pipelines.

[0059] Specifically, the above solution achieves the adaptability of the data conversion pipeline through a modular architecture and dynamic assembly mechanism. During system operation, when a diagnostic request or raw diagnostic data enters the pipeline, the pipeline assembler first analyzes the characteristics of the data, such as whether the protocol type is CAN, LIN, or other communication protocols, and whether the data format conforms to predefined standards. Based on these characteristics, the pipeline assembler selects appropriate components from the modular conversion component pool and dynamically generates a processing chain in the optimal order (e.g., first decrypting through component A, then format standardizing through component B) to complete the data processing. This dynamic decision-making mechanism based on data characteristics ensures that the processing steps accurately match the current data requirements, thereby significantly improving the efficiency and relevance of data processing. Furthermore, since each modular conversion component is developed and tested independently, it not only reduces the system's maintenance costs but also facilitates subsequent functional expansion. Combined with the functions of the service governance engine and the service instance layer, the above solution further enhances the flexibility and evolvability of the diagnostic system, meeting the needs of diverse protocols and complex diagnostic scenarios in modern automotive electronic architectures.

[0060] This technical solution transforms the fixed data processing chain into a dynamically assembleable modular pipeline. The pipeline assembler automatically selects and combines components based on the characteristics of the data itself (such as protocol type and data format) to form the optimal processing path. This avoids the performance bottleneck caused by "one-size-fits-all" data processing, enables on-demand customization and flexible optimization of the processing flow, improves the overall processing efficiency of the system, and thus enhances the overall performance and user experience of the diagnostic system.

[0061] In one embodiment, this application further proposes an intelligent resource scheduler with a built-in predictive model that continuously monitors historical load data, predicts resource demand based on historical load data, and if an upcoming request peak is predicted, it will issue dynamic scaling and load migration instructions to the service instance layer in advance to ensure service quality.

[0062] Specifically, an intelligent resource scheduler refers to a system component with data analysis and prediction capabilities. It can be implemented using machine learning-based time series prediction models, deep learning regression models, or statistical methods such as ARIMA models. Its purpose is to identify periodic patterns and sudden trends in diagnostic requests through the analysis of historical load data. A prediction model is an algorithmic module capable of extracting patterns from historical data and inferring future trends. It can be implemented using ensemble learning methods, neural network structures, or traditional statistical models, aiming to provide a scientific basis for resource scheduling. Dynamic scaling refers to the process of elastically adjusting the number of service instances based on prediction results. This can be achieved through container orchestration tools such as Kubernetes, virtual machine management platforms, or physical server cluster management strategies, aiming to optimize resource utilization. Load migration refers to the operation of transferring some diagnostic tasks from high-load nodes to low-load nodes. This can be achieved through distributed task scheduling frameworks, load balancers, or custom task distribution logic, aiming to improve the overall stability of the system.

[0063] In detail, this solution continuously monitors historical load data through an intelligent resource scheduler, building a forward-looking decision-making capability in the time dimension. During actual operation, the intelligent resource scheduler first collects and stores historical load data, including information such as the frequency, type, processing time, and resource usage of diagnostic requests. Subsequently, the predictive model analyzes this data to identify potential peak load periods or abnormal traffic patterns, such as concentrated testing demand on weekday mornings or a surge in diagnostic requests caused by recalls of specific vehicle models. Based on this, the intelligent resource scheduler generates dynamic scaling instructions, increasing the number of service instances in advance to cope with upcoming high loads, or reducing the number of instances to conserve resources when the load decreases. Simultaneously, load migration instructions ensure that when some service instances are overloaded, some tasks can be allocated to other idle instances, thereby avoiding single-point bottlenecks. This mechanism, combined with the protocol adaptation and context-aware routing functions in the aforementioned vehicle diagnostic service method, jointly improves the system's flexibility and reliability, enabling the diagnostic service to maintain efficient operation in complex and ever-changing in-vehicle environments.

[0064] The above technical solution upgrades passive reactive load balancing to proactive predictive resource scheduling. It can not only predict the peak and trend of service requests, but also release resources reasonably when resource demand is low. This enables proactive scaling up and down of service instances and load migration, thereby significantly improving the continuity and response efficiency of diagnostic services, reducing the risk of service interruption due to improper resource scheduling, and improving resource utilization and cost-effectiveness.

[0065] In one embodiment, this application further proposes releasing session resources after the diagnostic task is completed or fails, including disconnecting the protocol adapter association and cleaning up persistent state, updating the system resource state table, and marking the adapter as idle.

[0066] Specifically, disconnecting the protocol adapter association refers to detaching the protocol adapter from the current diagnostic session. This can be achieved by actively calling the unbinding interface or by triggering the unbinding operation through event-driven mechanisms. The goal is to enable the protocol adapter to quickly respond to new diagnostic requests. Cleaning up persistent state can be understood as deleting stored session state data. This can be achieved through scheduled cleanup tasks or event-triggered cleanup mechanisms. The goal is to eliminate the occupation of system storage by historical states. Updating the system resource state table refers to refreshing resource usage records in real time. This can be achieved through synchronous updates or asynchronous notifications. The goal is to provide context-aware routers with an accurate view of resources. Marking an adapter as idle can be understood as directly updating the adapter availability flag. This can be achieved through state machine transitions or flag settings. The goal is to facilitate the service governance engine in quickly identifying available resources.

[0067] In detail, after a diagnostic task is completed, the system first disconnects the protocol adapter, ensuring that the adapter can be immediately reused by other diagnostic requests, significantly improving the turnaround efficiency of protocol adaptation resources. The subsequent persistent state cleanup not only frees up storage space but also prevents residual data from interfering with subsequent diagnostic processes. Simultaneously, timely updates to the system resource status table provide context-aware routers with the latest resource usage information, enabling them to make more accurate intelligent routing decisions. Finally, by marking the adapter as idle, the service governance engine can quickly locate available resources when parsing new requests, thereby reducing scheduling latency and improving system response speed. These measures work together to ensure the efficient recycling of system resources and maintain the high availability and scalability of the diagnostic service.

[0068] In another embodiment, this application also discloses a system for implementing the above-described vehicle diagnostic service method based on dynamic protocol adaptation and context awareness, such as... Figure 2 As shown, it includes the service governance engine (G), context-aware router (R), protocol adaptation matrix (M), protocol adapter (A), data conversion pipeline (P), session manager (SM), and service instance layer (SI).

[0069] The service governance engine parses diagnostic requests, determining the required service scope and dependencies. The context-aware router acquires multi-dimensional context information and, based on this information and dependencies, performs routing decisions to select the optimal service instance and protocol path. The protocol adaptation matrix dynamically invokes protocol adapters based on service instances and protocol paths. The protocol adapter converts the diagnostic request into protocol messages for the vehicle network and receives the raw diagnostic data returned by the vehicle network. The session manager creates a session context container for each diagnostic. During data interaction, raw diagnostic data flows through an adaptive data conversion pipeline. The pipeline assembler dynamically selects and assembles necessary conversion components based on the data's protocol type, format, and other characteristics to complete data processing. Throughout the process, the intelligent resource scheduler continuously monitors system load. If an upcoming request peak is predicted, it preemptively expands the service instance pool with new service instances to ensure service quality. The session manager periodically or on demand persists the incremental state of the session container to ensure execution can resume from the breakpoint in case of anomalies.

[0070] This application effectively addresses the key issues of rigid protocol adaptation, flat service management, and singular routing decisions by combining a service governance engine, a context-aware router, a protocol adaptation matrix, and protocol adapters in a collaborative manner. Specifically, the service governance engine clarifies the functional boundaries and dependencies of services by parsing diagnostic requests, overcoming the lack of semantic description in service management in existing technologies; the context-aware router achieves intelligent routing decisions in complex vehicular environments by comprehensively evaluating multi-dimensional information such as vehicle status, system resources, and business policies; and the protocol adaptation matrix avoids static rule constraints by dynamically invoking protocol adapters, supporting plug-and-play functionality for multiple communication protocols. These technical features work together to significantly improve the flexibility and intelligence of diagnostic services.

[0071] The following describes the vehicle diagnostic service method in detail, taking into account the specific components of the vehicle diagnostic service system. The specific steps include: Step 1, Service Discovery and Routing Decision (Clarifying "Which Services to Call"): Receive diagnostic requests, confirm the scope of services the system can provide and their dependencies, and provide a basis for subsequent routing.

[0072] 1.1 The diagnostic client (D) generates a standardized diagnostic request (including request ID, diagnostic type, and target ECU identifier) ​​based on user requirements (such as "reading transmission ECU fault codes" or "detecting brake system sensors") and sends it to the service governance engine (G).

[0073] 1.2 The Service Governance Engine (G) queries the built-in "Service Capability Graph" (which records all diagnostic services that the system can provide, such as engine diagnostics, chassis diagnostics, etc.) to confirm whether the service corresponding to the current request exists.

[0074] 1.3 The service governance engine (G) resolves service dependencies (e.g., "reading transmission fault codes" requires executing "transmission ECU wake-up service" first to avoid direct calls leading to failure). After determining that there are no dependency conflicts, it passes the "request content + service requirement list" to the context-aware router (R).

[0075] Step 2, Multi-dimensional Context Awareness (Determining the "Optimal Execution Path"): Collect multi-dimensional environmental and system data, and dynamically select appropriate service instances and execution strategies through algorithms.

[0076] 2.1 The context-aware router (R) obtains three types of data through interfaces: Vehicle status data: Call the vehicle bus interface to obtain the current status of the target ECU (such as whether it is awake, whether the communication is normal) and the overall vehicle status (vehicle speed, oil temperature, battery voltage, to avoid performing non-emergency diagnostics while driving at high speed); System resource data: Query server CPU load, memory usage, and protocol adapter usage (e.g., whether the CAN adapter is idle to avoid resource contention). Business strategy data: Read preset rules (such as "fault diagnosis priority > regular data collection" and "emergency requests can preempt low-priority resources").

[0077] 2.2 Routing Decision Calculation: The context-aware router (R) executes a "weighted scoring algorithm" to comprehensively score candidate service instances (such as multiple CAN protocol service instances of the same type) according to "vehicle adaptability (40%), resource idleness (30%), and policy matching degree (30%)", selects the service instance with the highest score and its corresponding protocol (such as CAN FD, Ethernet), and generates a routing decision result (including target service instance ID, protocol type, and resource allocation scheme).

[0078] Step 3, Resource and Session Preparation (Ensuring Continuity of Request Processing): Initialize the session container, load historical states (if necessary), and pass execution instructions to the protocol adaptation layer to prepare for data transmission.

[0079] 3.1 Session Creation / Association: The context-aware router (R) sends the "routing decision result + request ID" to the session manager (SM).

[0080] 3.2 SM Judgment: If it is a new request (no historical session ID): Create a new "session context container" (to store subsequent request / response data and intermediate states) and generate a unique session ID; If it is a resume request (including historical session ID): query and associate the existing session container, and load the historical state (such as the instructions sent before the last interruption, and the partial response of the ECU).

[0081] 3.3 Session State Initialization: The SM configures basic parameters for the session container (such as timeout, data cache size, and number of retries) and feeds back "session ID + initial state" to the context-aware router (R).

[0082] 3.4 Protocol Adaptation Command Issuance: The context-aware router (R) transmits the command "Session ID + Use XX protocol (e.g., CAN) to execute YY service (e.g., read gearbox fault code)" to the protocol adaptation matrix (M).

[0083] Step 4, Protocol Adaptation and Data Transmission (Achieving "Request to ECU Communication"): Convert the diagnostic request into a protocol message that the vehicle ECU can recognize and send it to the target ECU of the vehicle (C).

[0084] 4.1 Protocol Adapter Selection: The protocol adapter matrix (M) selects the corresponding protocol adapter (A) from the adapter pool (including adapters for CAN, LIN, Ethernet, etc.) according to the "protocol type instruction" (such as CAN) and establishes a communication link between M and A.

[0085] 4.2 Raw Request Data Transformation: The protocol adaptation matrix (M) sends the "raw diagnostic request data + session ID" to the data transformation pipeline (P), and P executes the dynamically assembled transformation rules: Format conversion: Convert non-standard client requests (such as JSON format) into the system's internal "diagnostic standard instructions" (including instruction type, target ECU address, and data length); Validity check: Check whether the command conforms to the communication specifications of the target ECU (such as whether the CAN ID is within the legal range and whether the data length matches). If the check fails, an error is returned to the service governance engine (G).

[0086] 4.3 Protocol Message Encapsulation: The data conversion pipeline (P) passes the "standard instruction + session ID" to the protocol adapter (A). The A encapsulates the message according to the specified protocol specification (e.g., for the CAN protocol, a frame ID, data field, and check bit need to be added to generate a CAN FD message).

[0087] 4.4 Message transmission: The protocol adapter (A) sends the encapsulated message to the target ECU via the vehicle bus (such as CAN bus) and records the transmission time and message content (for subsequent traceability).

[0088] Step 5, Response Processing and Result Return (Complete "ECU Response Feedback to Client"): Receive the ECU response, parse it into a readable result, update the session state, and return it to the diagnostic client (D).

[0089] 5.1 Response reception: The protocol adapter (A) listens to the vehicle bus and waits for the response message from the target ECU (if it does not receive the response message within a timeout, a retry mechanism is triggered. If the retry fails 3 times, the "ECU not responding" error is returned).

[0090] 5.2 Raw Response Parsing: The protocol adapter (A) sends the received raw response message (such as binary CAN data) to the data conversion pipeline (P), and P performs the reverse conversion: Protocol unpacking: Remove the protocol header and checksum, and extract the core response data; Data structuring: Converting binary data into a readable format (e.g., resolving "0x02 0x01 0x03" to "fault code P0103 (high voltage in air flow sensor circuit)").

[0091] 5.3 Session State Update: The data conversion pipeline (P) sends "structured response data + session ID" to the session manager (SM). The SM incrementally updates the session container state (such as adding response time and response content). If it is a long-cycle task (such as batch diagnosis of multiple ECUs), the state is persisted to the database (to avoid loss during system restart).

[0092] 5.4 Diagnostic Result Processing: The data transformation pipeline (P) passes the "standardized diagnostic results" to the service instance (SI). The SI executes business logic (such as matching fault code descriptions, determining fault levels, and generating maintenance suggestions) to generate a complete diagnostic report.

[0093] 5.5 Result Return: The service instance (SI) passes the diagnostic report to the service governance engine (G). After G returns the report in a unified format (such as JSON / XML), it associates the request ID and sends the report back to the diagnostic client (D).

[0094] Step 6, Resource Cleanup (optional, to avoid "resource redundancy"): After the diagnostic task is completed / failed, release session resources to avoid memory leaks and resource waste.

[0095] 6.1 Cleanup Trigger: When the context-aware router (R) detects that "the diagnostic report has been returned to the client" (task completed) or "multiple retries have failed and no resumption is needed" (task terminated), it generates a "session cleanup instruction" (including session ID); 6.2 Resource Release: After receiving the instruction, the Session Manager (SM) performs the following operations: Release the memory resources occupied by the session container; Disconnect the associated links between the protocol adapter (A) and the data conversion pipeline (P); If the data is already in a persistent state, determine whether to retain historical logs (e.g., fault diagnosis logs should be retained for 3 months, and regular data collection logs should be retained for 7 days). If no need to retain them, delete the database records.

[0096] 6.3 Cleanup Confirmation: The Session Manager (SM) returns a "Resource cleanup complete" confirmation message to the Router (R), and the Router (R) updates the resource status (e.g., marking the CAN adapter as "idle").

[0097] By following the above 6 steps, a complete closed loop from "diagnostic request initiation" to "result feedback + resource cleanup" can be achieved. This not only meets the "multi-protocol, multi-ECU, and high reliability" requirements of vehicle diagnostic scenarios, but also facilitates subsequent process optimization and problem troubleshooting.

[0098] Those skilled in the art will understand that embodiments of the present invention can be provided as methods, systems, or computer program products. Therefore, the present invention can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, the present invention can take the form of a computer program product embodied on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0099] This invention is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the invention. It will 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 program instructions. These computer program instructions may also be stored in a computer-readable storage medium capable of directing a computer or other programmable data processing apparatus to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means implemented in the flowchart illustrations and / or block diagrams. Figure 1 One or more processes and / or boxes Figure 1The functions specified in one or more boxes. These computer program instructions may also be loaded onto a computer or other programmable data processing apparatus to cause a series of operational steps to be performed on the computer or other programmable apparatus to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable apparatus for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.

[0100] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention and not to limit its scope of protection. Although the present invention has been described in detail with reference to the above embodiments, those skilled in the art should understand that after reading the present invention, they can still make various changes, modifications, or equivalent substitutions to the specific implementation of the invention, but all such changes, modifications, or equivalent substitutions are within the scope of protection of the pending claims. Content not described in detail in this specification belongs to the prior art known to those skilled in the art.

Claims

1. A vehicle diagnostic service method based on dynamic protocol adaptation and context awareness, characterized in that: The diagnostic request is parsed to determine the service scope and dependencies required by the diagnostic request. Obtain multi-dimensional context information, and based on the obtained information and the aforementioned dependencies, perform routing decisions to select the optimal service instance and protocol path; Based on the service instance and protocol path, the protocol adapter is dynamically invoked through the protocol adaptation matrix to convert the diagnostic request into a protocol message and send it to the vehicle network; Receive raw diagnostic data returned from the vehicle network to generate a complete diagnostic report.

2. The vehicle diagnostic service method based on dynamic protocol adaptation and context awareness according to claim 1, characterized in that: The diagnostic requests are parsed through a service governance engine, which embeds a diagnostic service capability graph. This diagnostic service capability graph is a knowledge base that stores semantic descriptions of diagnostic services, dependencies, and compositional logic.

3. The vehicle diagnostic service method based on dynamic protocol adaptation and context awareness according to claim 1, characterized in that: By connecting vehicle status sensors, system resource monitors, and business policy libraries through a context-aware router, multi-dimensional contextual information including vehicle status, system resources, and business policies can be obtained.

4. The vehicle diagnostic service method based on dynamic protocol adaptation and context awareness according to claim 1, characterized in that, The step of performing routing decisions and selecting the optimal service instance and protocol path based on the acquired information and the dependencies includes: Context-aware routers perform constraint filtering on all candidate service instances based on service dependencies, excluding service instances that do not meet the dependency requirements. A weighted scoring algorithm is used to score the remaining candidate service instances from three aspects: vehicle adaptability, resource availability, and policy matching. The service instance with the highest score and its corresponding protocol path are selected as the optimal route.

5. The vehicle diagnostic service method based on dynamic protocol adaptation and context awareness according to claim 1, characterized in that, The step of dynamically invoking the protocol adapter through the protocol adaptation matrix to convert the diagnostic request into a protocol message and send it to the vehicle network includes: The protocol adaptation matrix selects a protocol adapter corresponding to the protocol path from the adapter pool, and encapsulates the diagnostic request into a protocol message that conforms to the vehicle communication protocol standard and sends it to the vehicle network through the selected protocol adapter. The protocol adaptation matrix internally encapsulates a protocol feature description library and a protocol conversion mapping rule library, and is capable of receiving registration information from different protocol adapters.

6. The vehicle diagnostic service method based on dynamic protocol adaptation and context awareness according to claim 1, characterized in that: After selecting the optimal service instance and protocol path, a context container for the diagnostic session is created and managed through the session manager. The context container is a lightweight data structure used to store incremental state changes of the diagnostic session, and the state is saved and restored through persistent storage of session state.

7. The vehicle diagnostic service method based on dynamic protocol adaptation and context awareness according to claim 1, characterized in that, Also includes: The diagnostic requests are formatted and validated using a data conversion pipeline. The processed data is sent to the vehicle network as protocol messages via the protocol adapter; The data conversion pipeline performs protocol unpacking, format conversion, and legality verification on the raw diagnostic data returned by the vehicle network to generate standardized diagnostic results. A complete diagnostic report is generated from standardized diagnostic results through the service instance layer.

8. The vehicle diagnostic service method based on dynamic protocol adaptation and context awareness according to claim 7, characterized in that: The data conversion pipeline consists of several pluggable modular conversion components. The pipeline assembler dynamically combines these modular conversion components into a processing chain based on the data characteristics to process the data flowing through it.

9. The vehicle diagnostic service method based on dynamic protocol adaptation and context awareness according to claim 1, characterized in that: It also includes an intelligent resource scheduler that continuously monitors historical load data through a built-in predictive model, predicts resource demand based on historical load data, and issues dynamic scaling and load migration instructions to the service instance layer.

10. A system for implementing the vehicle diagnostic service method based on dynamic protocol adaptation and context awareness as described in claim 1, characterized in that: include The service governance engine is used to parse diagnostic requests and determine the service scope and dependencies required by the diagnostic requests. A context-aware router is used to acquire multi-dimensional context information and, based on the acquired information and the dependencies, to perform routing decisions and select the optimal service instance and protocol path. A protocol adaptation matrix is ​​used to dynamically invoke the protocol adapter based on the service instance and protocol path. A protocol adapter is used to convert the diagnostic request into a protocol message and send it to the vehicle network, and to receive the raw diagnostic data returned by the vehicle network.

Images