Functional layer and protocol analysis layer decoupling vehicle-mounted diagnostic system architecture and diagnostic method

Abstract

The invention discloses a function layer and protocol analysis layer decoupling vehicle-mounted diagnosis system architecture and a diagnosis method, and the system comprises a function service unit group which is used for sending an abstract diagnosis request to a protocol adaptation bus when a diagnosis operation is executed; the protocol adapter group is used for executing diagnosis operation based on the abstract diagnosis request and sending semantically packaged response data to the protocol adaptation bus; and the protocol adaptation bus is connected between the function service unit group and the protocol adapter group, and is used for transmitting abstract diagnosis requests and response data to the protocol adapter group and the function service unit group respectively, so that decoupling of the function layer and the protocol analysis layer is realized. Through collaborative design of the function service unit group, the protocol adapter group and the protocol adaptation bus, diagnosis function realization and a protocol analysis process are separated, flexible switching between independent evolution of diagnosis service and protocol adaptation is realized, and the method has the advantages of improving system maintainability, expandability and cross-platform compatibility.

Description

Technical Field

[0001] This invention belongs to the field of automotive electronic diagnostic technology, specifically relating to an on-board diagnostic system architecture and diagnostic method that decouples the functional layer and protocol parsing layer. Background Technology

[0002] Traditional automotive diagnostic system architectures typically employ a tightly coupled design at the vehicle's infotainment system level, deeply binding diagnostic functions to specific vehicle communication protocols. For example, diagnostic functions such as fault code lookup or controller upgrades are directly embedded in the implementation code of protocols like CAN or DoIP, resulting in a highly rigid system structure. This design presents several technical obstacles: In protocol evolution scenarios, when vehicle communication standards upgrade from traditional bus protocols to new network protocols, all diagnostic function modules need to be redeveloped and adapted, leading to significant duplication of development resources; during cross-platform migration, diagnostic logic customized for specific operating systems cannot be directly reused in heterogeneous environments, significantly increasing multi-platform deployment costs; in system maintenance, the code of the protocol parsing layer and the business logic layer is intertwined, and modifications to any single layer can trigger compatibility issues in another layer, making the testing and verification process exceptionally complex and error-prone; regarding functional expansion, the rigid coupling between the functional layer and the protocol layer limits the dynamic combination capabilities of diagnostic services, for example, preventing the flexible integration of special process controls and controller upgrade operations according to actual diagnostic needs, severely restricting system adaptability and scalability. The aforementioned shortcomings make it difficult for traditional architectures to meet the urgent needs of modern intelligent connected vehicles for efficient iteration and flexible deployment of diagnostic systems.

[0003] To address the aforementioned issues, existing technologies urgently need improvement. Summary of the Invention

[0004] The purpose of this invention is to address the shortcomings of the aforementioned background technology by providing an on-board diagnostic system architecture and diagnostic method that decouples the functional layer from the protocol parsing layer. This architecture improves system maintainability, scalability, and cross-platform compatibility while reducing development and maintenance costs.

[0005] The technical solution adopted in this invention is: an on-board diagnostic system architecture with decoupled functional layer and protocol parsing layer, including... The functional service unit group is used to provide diagnostic business functions and sends abstract diagnostic requests to the protocol adaptation bus when performing diagnostic operations. The protocol adapter group is capable of adapting to different vehicle communication protocols and operating system platforms, and is used to perform diagnostic operations based on abstract diagnostic requests and send semantically encapsulated response data to the protocol adapter bus. The protocol adaptation bus connects the functional service unit group and the protocol adapter group, and is used to transmit abstract diagnostic request and response data to the protocol adapter group and the functional service unit group respectively, thereby decoupling the functional layer from the protocol parsing layer.

[0006] Furthermore, the functional service unit group includes at least one of a tool interaction unit, a file processing unit, a diagnostic core unit, and a control execution unit; The tool interaction unit is used to carry the front-end interaction logic of configuration tools, diagnostic tools, process tools, and full vehicle diagnostics; The file processing unit is used to parse and process XML, PDX configuration files, and software upgrade packages; The diagnostic core unit is used to provide diagnostic services, logistics information query, fault code query and real-time data display. The control execution unit is used to perform control, routine control, special process driving, and controller upgrades.

[0007] Furthermore, the protocol adapter group includes a protocol parsing module and a platform interface library; The protocol parsing module is used to convert abstract diagnostic requests into specific diagnostic operation sequences, match appropriate diagnostic capabilities to the diagnostic operation sequences, and finally form protocol messages that conform to vehicle communication protocol standards; it is also used to semantically encapsulate raw diagnostic data and convert it into semantically rich response data. The platform interface library is an access interface for connecting to the vehicle network. It is used to send protocol messages to the vehicle network and transmit the raw diagnostic data returned by the vehicle network to the protocol parsing module.

[0008] Furthermore, the protocol parsing module includes a protocol adaptation matrix and several different protocol adapters connected to the protocol adaptation matrix; The protocol adaptation matrix internally encapsulates a protocol feature description library and a protocol conversion mapping rule library, which are used to receive the registration information of the protocol adapter and send abstract diagnostic requests to the protocol adapter. The protocol adapter is used to convert abstract diagnostic requests into protocol messages that conform to the vehicle communication protocol standard.

[0009] Furthermore, the protocol adaptation bus is configured with a standardized interface specification that is independent of specific protocols and platforms, used to register protocol adapters and route abstract diagnostic requests, supporting dynamic addition, deletion, or replacement of protocol adapters.

[0010] Furthermore, it also includes a session context management unit, which is used to maintain and manage context information during the diagnostic process.

[0011] Furthermore, the management session context unit includes 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 combinational logic. The service governance engine is used to receive diagnostic requests sent by the protocol adaptation matrix of the protocol parsing module, and to perform service parsing and matching based on the diagnostic service capability graph.

[0012] Furthermore, the management session context unit includes a context-aware router, which is connected to a vehicle status sensor, a system resource monitor, and a service policy library. It is used to acquire multi-dimensional context information including vehicle status, system resources, and service policies, and to execute a routing decision algorithm based on the acquired information to output the optimal service instance and protocol path to the service instance layer.

[0013] Furthermore, the management session context unit includes an incremental session manager, which is used to create and manage context containers for diagnostic sessions; the context container is a lightweight data structure used to store incremental state changes of the diagnostic session, and to save and restore the state through persistent storage of session state.

[0014] Furthermore, the management session context unit includes an intelligent resource scheduler, which has a built-in prediction model for predicting resource demand based on historical load data and issuing dynamic scaling and load migration instructions to the service instance layer.

[0015] Furthermore, the management session context unit includes an adaptive data conversion pipeline, which consists of several pluggable modular conversion components. The pipeline assembler dynamically combines these modular conversion components into a processing chain based on data characteristics, and performs verification, format conversion, or encryption on the data flowing through it.

[0016] A diagnostic method for an on-board diagnostic system architecture based on the above-mentioned decoupling of the functional layer and protocol parsing layer includes the following steps: Receive abstract diagnostic requests sent by the functional service unit group; Transform abstract diagnostic intentions into a specific sequence of diagnostic operations; Match appropriate diagnostic capabilities to the diagnostic procedure sequence; Perform diagnostic operations according to the diagnostic operation sequence and obtain raw diagnostic data; Transform raw diagnostic data into semantically rich response data; Send response data to the functional service unit group.

[0017] The beneficial effects of this invention are as follows: This invention separates the implementation of diagnostic functions from the protocol parsing process through the collaborative design of functional service unit groups, protocol adapter groups, and protocol adaptation buses. This avoids the problem of system-wide redevelopment caused by protocol changes in traditional tightly coupled architectures, and realizes independent evolution of diagnostic services and flexible switching of protocol adaptation. It has the advantages of improving system maintainability, scalability, and cross-platform compatibility, while reducing development and maintenance costs.

[0018] This invention achieves a high degree of modularity and flexibility: because functional service units and protocol adapters are decoupled via the bus, the system can dynamically add, remove, or replace protocol adapters like "plug-and-play components." For example, when support for a new automotive Ethernet protocol is required, only a new protocol adapter needs to be developed and registered on the bus; all existing functional service units can immediately gain support for the new protocol without any modification. This greatly enhances the system's ability to adapt to technological iterations and vehicle model differences.

[0019] This invention improves code reusability and maintainability: the business logic of each functional service unit (such as "controller upgrade") is pure and unique, and can be reused without loss on any platform equipped with the corresponding protocol adapter (whether DLL or JAR package). At the same time, changes to the communication protocol are isolated within the adapter, making the boundaries of code maintenance clear and reducing the complexity of testing and debugging.

[0020] This invention enhances the system's configurability and scalability: the protocol adaptation bus acts as a configurable routing center, allowing for flexible specification of the protocol adapters to be used in different vehicle models or scenarios through configuration files. Furthermore, the expansion of new diagnostic functions becomes a modular development approach: primarily implemented by writing new functional service units, while flexibly reusing existing protocol adaptation capabilities, significantly reducing development difficulty and time. Attached Figure Description

[0021] Figure 1 This is a schematic diagram of the vehicle-mounted diagnostic system architecture of the present invention.

[0022] Figure 2 This is a schematic diagram of the present invention incorporating a session management context unit.

[0023] Figure 3 This is a flowchart illustrating the on-board diagnostics process for this invention. Detailed Implementation

[0024] 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.

[0025] 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.

[0026] like Figure 1 As shown, this application proposes an on-board diagnostic system architecture that decouples the functional layer from the protocol parsing layer, including... The functional service unit group is used to send abstract diagnostic requests to the protocol adaptation bus when performing diagnostic operations; Protocol adapter group, used to perform diagnostic operations based on abstract diagnostic requests and send semantically encapsulated response data to the protocol adaptation bus; The protocol adaptation bus connects the functional service unit group and the protocol adapter group, and is used to transmit abstract diagnostic request and response data to the protocol adapter group and the functional service unit group respectively, thereby decoupling the functional layer from the protocol parsing layer.

[0027] In practical applications, the functional service unit group can be understood as the system's business logic layer, applied to the client side. It consists of multiple highly cohesive, functionally independent service units, and its main function is to generate diagnostic requests independent of specific protocols. For example, the functional service unit group can define diagnostic tasks through configuration files and convert these tasks into abstract diagnostic requests in a unified format, or it can receive input through the user interface and generate corresponding diagnostic requests. Furthermore, the functional service unit group can also use scripting languages ​​to describe the diagnostic logic, thereby dynamically generating abstract diagnostic requests to adapt to different diagnostic needs.

[0028] The protocol adapter group is the system's communication logic layer, applied on the server side. Its function is to transform abstract diagnostic requests into concrete diagnostic operations and to semantically encapsulate the diagnostic results. It consists of a series of adapter modules targeting different communication protocols and operating system platforms. Specifically, the protocol adapter group can employ rule engine technology to convert abstract diagnostic requests into operation sequences conforming to specific communication protocols based on predefined mapping rules. For example, the protocol adapter group can support multiple vehicle communication protocols by loading different protocol plugins, or it can generate and parse protocol messages by calling external libraries. Furthermore, the protocol adapter group can utilize middleware technology to semantically encapsulate raw diagnostic data, thereby improving data readability and usability.

[0029] The protocol adaptation bus acts as a bridge between the functional service unit group and the protocol adapter group, with its core function being to decouple the two. Specifically, the protocol adaptation bus can employ a message queue mechanism to achieve asynchronous communication, ensuring efficient transmission of diagnostic request and response data. For example, the protocol adaptation bus can route abstract diagnostic requests to appropriate protocol adapters using a publish-subscribe pattern, or optimize request distribution efficiency using load balancing algorithms. Furthermore, the protocol adaptation bus can also ensure compatibility and interoperability between different modules by defining standardized interface specifications.

[0030] The innovation of this application lies in decoupling the functional layer from the protocol parsing layer by constructing a collaborative architecture of functional service unit groups, protocol adapter groups, and a protocol adaptation bus. As a result, the functional layer does not need to be aware of specific protocol details, but only needs to focus on diagnostic business logic, avoiding the problem of redeveloping the functional layer due to protocol changes. Simultaneously, the protocol parsing layer can independently adapt to different vehicle communication protocols without modifying the functional layer code, enhancing the system's flexibility and maintainability. Furthermore, the protocol adaptation bus, acting as a connection intermediary, achieves isolation between the functional layer and the protocol parsing layer through standardized interaction, ensuring that changes to either do not affect each other, thereby simplifying system maintenance and supporting dynamic function combinations.

[0031] The working principle of this embodiment is as follows: When performing diagnostic operations, the functional service unit group generates an abstract diagnostic request and sends the request to the protocol adaptation bus. The protocol adaptation bus, acting as a connection intermediary between the functional layer and the protocol parsing layer, is responsible for receiving the abstract diagnostic request and routing it to the protocol adapter group. The protocol adapter group executes specific diagnostic operations based on the received abstract diagnostic request and generates response data in a semantically encapsulated form of the diagnostic results. The response data is then transmitted back to the functional service unit group via the protocol adaptation bus. Thus, the functional layer does not need to be aware of specific protocol details and only needs to focus on the implementation of diagnostic business logic, thereby avoiding the problem of redeveloping the functional layer due to protocol changes and significantly improving the reusability and portability of diagnostic functions. Furthermore, the protocol adapter group can independently adapt to different vehicle communication protocols without modifying the functional layer code, enhancing the flexibility and maintainability of the protocol parsing layer. In addition, the protocol adaptation bus achieves isolation between the functional layer and the protocol parsing layer through standardized interface specifications, ensuring that changes to both do not affect each other, simplifying the system maintenance process, and supporting dynamic function combinations. The overall architecture forms a loosely coupled mechanism through the coordinated operation of the functional service unit group, the protocol adapter group, and the protocol adaptation bus, which effectively solves the problems of poor portability, low reusability, difficult maintenance, and rigid functions caused by the traditional tightly coupled architecture.

[0032] In one embodiment, this application further proposes a functional service unit group including at least one of a tool interaction unit, a file processing unit, a diagnostic core unit, and a control execution unit; the tool interaction unit is used to carry front-end interaction logic such as configuration tools, diagnostic tools, process tools, and full vehicle diagnostics; the file processing unit is used to parse and process configuration files such as XML and PDX, as well as software upgrade packages; the diagnostic core unit is used to provide core diagnostic services such as diagnostic services, logistics information query, fault code query, and real-time data display; and the control execution unit is responsible for the execution of specific control instructions, including I / O control, routine control, special process driving, and controller upgrades.

[0033] Specifically, the tool interaction unit refers to the functional module responsible for interacting with the user. It can be implemented using a graphical interface, command-line interface, or remote call interface. The purpose is to separate the front-end interaction logic from the underlying diagnostic logic, thereby allowing different platforms to independently optimize the interaction experience. The file processing unit can be understood as a functional module specifically designed to process files of a specific format. It can be implemented using rule-based parsers, scripting languages, or third-party libraries, aiming to simplify the adaptation process when adding new file types and improve the system's adaptability to diverse configurations. The diagnostic core unit refers to the core module that centrally provides diagnostic-related services. It can be implemented using service interfaces, message queues, or event-driven architecture, aiming to avoid redundant development of functions and ensure unified management and efficient reuse of core operations. The control execution unit refers to the functional module that independently executes control-related tasks. It can be implemented using a state machine model, script engine, or dynamic task scheduler to support flexible combination and dynamic adjustment in complex diagnostic scenarios.

[0034] Specifically, the aforementioned functional service unit group decomposes the abstract request sending function of diagnostic operations into multiple specialized units, achieving a refined modular design of the functional layer. The tool interaction unit carries the front-end interaction logic, separating user interface operations from the underlying diagnostic logic, solving the problem of intertwined interaction code and protocol parsing in traditional architectures, thereby improving cross-platform flexibility. The file processing unit focuses on parsing configuration files and upgrade packages, decoupling file format conversion from business logic through a modular processing mechanism, significantly reducing the adaptation difficulty when adding new file types. The diagnostic core unit, as the service hub, is called by other units, centrally providing diagnostic services and data query functions, avoiding redundant development of functions and ensuring efficient reuse of core operations. The control execution unit independently executes control tasks, supporting the dynamic combination of routine control and upgrade processes according to diagnostic needs, breaking through the limitations of traditional rigid functions. Overall, the clear division of labor and collaborative work among the units not only reduces the internal complexity of the functional layer but also provides structured support for the abstract request processing of the protocol adaptation bus, strengthening the system's robustness in cross-platform migration and functional expansion.

[0035] Through the above technical solutions, the design of the functional service unit group effectively solves the problem of high coupling between functional modules, significantly improves the maintainability and cross-platform reusability of the system, and lays a solid foundation for the flexible combination and expansion of diagnostic functions.

[0036] In one embodiment, this application further proposes a protocol adapter group including a protocol parsing module and a platform interface library. The protocol parsing module is used to convert abstract diagnostic requests into specific diagnostic operation sequences, match appropriate diagnostic capabilities to the diagnostic operation sequences, and ultimately form protocol messages conforming to vehicle communication protocol standards; it is also used to semantically encapsulate raw diagnostic data and convert it into semantically rich response data. The platform interface library is an access interface for connecting to the vehicle network, used to send protocol messages to the vehicle network and transmit the raw diagnostic data returned by the vehicle network to the protocol parsing module.

[0037] In practical applications, the protocol parsing module is the core component responsible for handling diagnostic requests and responses. It can be implemented using a rule-engine-based protocol converter or a scripting language-based dynamic parser. Its purpose is to support dynamic adaptation to various vehicle communication protocols through flexible protocol parsing logic, enabling message assembly, parsing, and status management for specific vehicle communication protocols such as DOIP. The platform interface library can be understood as a network communication layer independent of the protocol parsing logic. It can encapsulate operating system-specific hardware access interfaces, such as DLL dynamic link libraries for the Windows platform and Android JAR packages for the Android platform. Its purpose is to provide a unified network access interface to reduce the impact of underlying hardware changes on the system.

[0038] Specifically, this solution divides the protocol adapter group into two independent functional units: a protocol parsing module and a platform interface library, clearly defining their respective responsibilities. The protocol parsing module focuses on transforming abstract diagnostic requests from the functional layer into specific diagnostic operation sequences, dynamically matching diagnostic capabilities based on current protocol characteristics, and ultimately generating protocol messages conforming to vehicle communication protocol standards. This process ensures that the functional layer does not need to be aware of specific protocol details, thus achieving protocol independence. Simultaneously, the protocol parsing module also undertakes the task of semantically encapsulating the raw diagnostic data returned from the vehicle network, enabling the functional layer to directly process semantically rich response data, simplifying business logic development. The platform interface library, as an independent network access interface, is responsible for sending protocol messages and receiving raw diagnostic data. When the network interface changes, only the platform interface library needs to be replaced, without modifying the protocol parsing module. This design not only solves the problem of tight coupling within the protocol adapter group but also, through cooperation with the functional service unit group and the protocol adaptation bus, forms a complete decoupled architecture, significantly improving the system's maintainability and scalability.

[0039] Through the above technical solutions, the protocol adapter group effectively separates the protocol parsing logic from the network communication function, enabling the system to be independently updated and maintained at a lower cost when faced with changes in vehicle communication protocols or adjustments to network interfaces, while also enhancing the reusability of components across different operating system platforms.

[0040] In one embodiment, this application further proposes a protocol parsing module including a protocol adaptation matrix and several different protocol adapters connected to the protocol adaptation matrix. The protocol adaptation matrix, as the core component of the protocol adaptation layer, is a dynamic management and routing hub, internally encapsulating a protocol feature description library and a protocol conversion mapping rule library. It is used to receive registration information from protocol adapters and send abstract diagnostic requests to them. Simultaneously, it connects to the service governance engine through an uplink interface. The protocol adapters are used to convert the abstract diagnostic requests into protocol messages conforming to vehicle communication protocol standards. The multiple different adapters are independent functional modules deployed in parallel. Each adapter is specifically responsible for interacting with a specific vehicle communication protocol (such as a CAN adapter, LIN adapter, etc.), and they are connected to the protocol adaptation matrix through standardized interfaces.

[0041] In practical applications, the protocol adaptation matrix, serving as a core component of the central coordination hub, can be implemented using a knowledge-based dynamic scheduling system. Its purpose is to achieve modularity and dynamic expansion capabilities for protocol parsing logic by uniformly managing the registration and request distribution of protocol adapters. The protocol feature description library is a database storing characteristic information of various vehicle communication protocols. It can be implemented using structured data tables or semantic knowledge graphs, aiming to provide basic information support such as format and timing required for protocol parsing. The protocol conversion mapping rule library is a set of rules storing the semantic mapping logic from abstract requests to specific operations. It can be implemented using a rule engine or decision tree algorithm, aiming to achieve intelligent parsing and adapter matching of abstract diagnostic requests. The protocol adapter is an independent component dedicated to handling specific protocol conversion tasks. It can be implemented using a plug-in architecture or microservices, aiming to encapsulate protocol details within the adapter, enhancing system maintainability and reusability.

[0042] Specifically, the above scheme uses a protocol adaptation matrix as its core hub to achieve unified management and dynamic scheduling of multiple independent protocol adapters. The protocol feature description library and protocol conversion mapping rule library encapsulated within the protocol adaptation matrix work together to intelligently parse the intent of abstract diagnostic requests and automatically match the most suitable protocol adapter. When a new protocol adapter starts, it registers its supported protocol capabilities with the protocol adaptation matrix, which then constructs a dynamic service directory based on this information. During the diagnostic process, after an abstract diagnostic request arrives at the protocol adaptation matrix, it is matched in real-time according to the service directory and accurately routed to the corresponding protocol adapter. Each protocol adapter focuses on handling the conversion task of a specific protocol, generating protocol messages conforming to vehicle communication protocol standards based on the semantic description of the abstract diagnostic request. This design not only avoids the intrusive modification problems caused by traditional hard-coding methods but also significantly improves the system's scalability and adaptability. Furthermore, this scheme, combined with the standardized interface specifications of the protocol adaptation bus, further enhances the decoupling effect between the functional layer and the protocol parsing layer, effectively solving the problem of needing to refactor the core code when adding a new protocol adapter.

[0043] In one embodiment, this application further proposes a protocol adapter bus configuration with a standardized interface specification that is completely independent of specific protocols and platforms, used to register protocol adapters and route abstract diagnostic requests.

[0044] Specifically, the protocol adaptation bus is an abstract communication layer introduced between the functional service unit group and the protocol adapter group. Its main function is to decouple the functional layer from the protocol parsing layer. All access requests from functional service units to lower-layer resources must be forwarded through this bus; all protocol adapters must also register and expose services provided by the upper layer through this bus. In practical applications, the standardized interface specification can be a set of predefined APIs or communication contracts, which can be implemented using technologies such as RESTful APIs, gRPC, or message queues. The purpose is to provide a unified access method and interaction rules for protocol adapters. Registering protocol adapters refers to declaring and recording the capabilities of protocol adapters into the protocol adaptation bus through standardized interface specifications. This can be implemented using a plug-in mechanism or service discovery mechanism to simplify the integration process of new protocols. Furthermore, abstract diagnostic request routing refers to the process of dynamically distributing abstract diagnostic requests based on semantic features. This can be implemented using a rule engine or intelligent routing algorithm to improve the flexibility and accuracy of request distribution.

[0045] In detail, the above solution optimizes the core interaction mechanism of the protocol adapter bus by introducing standardized interface specifications. As a key component connecting the functional service unit group and the protocol adapter group, the protocol adapter bus achieves dynamic registration of protocol adapters through standardized interface specifications. This eliminates the need to modify the underlying bus code when adding or replacing vehicle communication protocols, significantly improving system scalability. Simultaneously, the routing mechanism for abstract diagnostic requests operates based on standardized interface specifications, intelligently identifying the semantic features of requests and accurately matching them to the corresponding protocol adapter, avoiding the rigidity issues caused by traditional hard-coded routing logic. Based on this, the above solution, together with the functional service unit group and the protocol adapter group, ensures efficient transmission of abstract diagnostic request and response data between the functional layer and the protocol parsing layer, further strengthening their isolation and providing a reliable foundation for efficient collaboration of the on-board diagnostic system in a multi-protocol environment.

[0046] The above technical solutions not only solve the bottleneck problems of dynamic integration and request distribution during protocol extension, but also effectively support the deep decoupling of the functional layer and the protocol parsing layer, significantly improving the system's portability, reusability, and maintenance efficiency.

[0047] In one embodiment, this application further proposes including a session context management unit, such as... Figure 2 As shown, the session context management unit is used to maintain and manage context information during the diagnostic process.

[0048] Specifically, the session context management unit refers to a logical unit for centralized management and diagnosis of session state, which can be implemented as a standalone software module, a distributed service component, or an embedded hardware module. In practical applications, this module dynamically tracks and stores key context data such as session identifiers, state variables, and operation history, avoiding the fragmentation problem caused by context information being scattered across functional service unit groups or protocol adapter groups, thereby ensuring the continuity and recoverability of the diagnosed session state.

[0049] In detail, during diagnostic operations, the session management context unit captures and stores key context information of the diagnostic session in real time through interaction with the functional service unit group and the protocol adapter group. When a diagnostic session is interrupted due to an anomaly, this module can quickly restore the previous state based on the stored context data, reducing redundant operations and resource waste. Simultaneously, in multi-task concurrent processing scenarios, the session management context unit effectively avoids mutual interference between sessions by isolating and managing the states of different sessions. Furthermore, this module provides unified context support for subsequent advanced functions such as service governance and resource scheduling, further enhancing the robustness and flexibility of the diagnostic process. In the above architecture, the session management context unit, together with the protocol adaptation bus, functional service unit group, and protocol adapter group, significantly improves the overall reliability and diagnostic efficiency of the system.

[0050] In practical applications, the service instance layer manages the business logic of the session, while the session management context unit handles the technical implementation of the session. For example, the service instance layer decides when to establish / terminate a session (business timing), while the session management context unit is responsible for how to establish / terminate the session (technical implementation); the service instance layer manages the state of the session in the business process, while the session management unit maintains the state of the session at the protocol level.

[0051] In one embodiment, this application further proposes a management session context unit including a service governance engine, which embeds a diagnostic service capability graph. The diagnostic service capability graph is a knowledge base storing semantic descriptions, dependencies, and combinational logic of diagnostic services. The service governance engine is used to receive diagnostic requests sent by the protocol adaptation matrix of the protocol parsing module, perform service parsing and matching according to the diagnostic service capability graph, and then pass the decision results to the context-aware router.

[0052] Specifically, the service governance engine refers to a core component with intelligent decision-making capabilities. It can be implemented using a rule-based engine, machine learning model, or hybrid architecture. Its purpose is to dynamically parse and match diagnostic requests through a built-in diagnostic service capability graph. The diagnostic service capability graph can be understood as a structured knowledge base, which can be built in the form of a graph database, relational database, or semantic web. Its purpose is to store semantic descriptions, dependencies, and composition logic of diagnostic services, thereby supporting flexible service composition and dynamic adaptation.

[0053] In detail, the service governance engine implements an intelligent parsing and matching mechanism for diagnostic requests through an embedded diagnostic service capability graph. In actual operation, the service governance engine receives diagnostic requests from the protocol adaptation matrix sent by the protocol parsing module. These requests carry protocol characteristics and real-time status information. Based on the semantic descriptions in the diagnostic service capability graph, the service governance engine parses the diagnostic requests, identifies the service intent, and generates the optimal service path by combining stored dependencies and composition logic. This process fully leverages the advantages of semantic descriptions over traditional hard-coded logic, enabling the system to accurately understand the inherent relationships and execution constraints between services, thereby supporting flexible service composition in complex diagnostic scenarios. Furthermore, since the protocol adaptation matrix is ​​a core component of the protocol parsing module, its diagnostic requests are deeply coupled with the protocol context. The service governance engine fully considers the dynamic characteristics of vehicle communication protocols during the parsing process, ensuring the accuracy and adaptability of the parsing results.

[0054] Through the above technical solutions, the system not only overcomes the problem of rigid service composition in traditional decoupled architectures, but also significantly improves the adaptability and maintainability of the diagnostic system, especially demonstrating excellent performance under changing diagnostic scenarios and protocol requirements.

[0055] In one embodiment, this application further proposes a management session context unit including a context-aware router. The context-aware router is connected to multiple context collectors, including a vehicle status sensor (collecting network latency and ECU online status), a system resource monitor (collecting CPU and memory usage), and a service policy library (storing SLAs and priority rules). It is used to obtain multi-dimensional context information containing vehicle status, system resources, and service policies, and to execute a routing decision algorithm based on the obtained information to output the optimal service instance and protocol path to the service instance layer.

[0056] Specifically, a context-aware router is a component capable of integrating multi-source information and making intelligent routing decisions. It can be implemented using algorithms based on rule engines, machine learning models, or hybrid decision-making mechanisms. Vehicle status sensors are devices capable of collecting vehicle operation data in real time; these can be onboard CAN bus interfaces, OBD interfaces, or other dedicated data acquisition devices. System resource monitors are modules used to monitor computing resource usage; they can be implemented through operating system APIs or dedicated monitoring tools. Business policy libraries are databases that store diagnostic-related business rules; they can be implemented using relational databases or NoSQL databases. The purpose of introducing these components is to build a comprehensive environment-aware model, providing reliable data support for dynamic routing decisions.

[0057] In detail, this solution establishes connections with multiple information sources through a context-aware router, forming a complete diagnostic decision support system. The context-aware router acquires real-time vehicle status information, such as vehicle speed and fault signals, from vehicle status sensors, ensuring that diagnostic operations do not interfere with critical driving scenarios. It also monitors memory and CPU usage through a system resource monitor to assess service load capacity and avoid selecting high-consumption service instances when resources are scarce. Furthermore, it uses predefined rules in a business policy library to constrain routing selection to meet actual business needs. This multi-dimensional information integration effectively overcomes the limitations of single-dimensional decision-making, enabling the system to prioritize high-precision diagnostic services when the vehicle is stationary and resources are sufficient, and switch to lightweight paths when resources are limited. Simultaneously, this solution, combined with the decoupled architecture of the aforementioned functional and protocol parsing layers, further enhances the system's adaptability and real-time response capabilities, achieving deep collaboration between the diagnostic process and the vehicle's operating status.

[0058] The above technical solutions not only enhance the intelligence level of context management, but also significantly improve the efficiency and stability of the diagnostic system, providing an innovative solution for the optimization of vehicle diagnostic systems.

[0059] In one embodiment, this application further proposes that the management session context unit in the above-mentioned vehicle diagnostic system architecture includes an incremental session manager. The incremental session manager is used to create and manage the context container of the diagnostic session. The context container is a lightweight data structure used to store the incremental state changes of the diagnostic session, and the state is saved and restored through persistent storage of session state (such as a database or cache).

[0060] Specifically, an incremental session manager is a component capable of dynamically tracking and managing changes in the state of diagnostic sessions. It can be implemented using an event-driven state capture mechanism or a time-interval-triggered state snapshot mechanism, aiming to reduce system resource consumption and improve state management efficiency. The context container is a data carrier specifically designed to store diagnostic session state information. It can be implemented using a key-value pair-based sparse data structure or a differential record table, aiming to record critical state changes with minimal storage overhead. In practical applications, persistent session state storage can be understood as a technique for efficiently writing incremental state changes to non-volatile storage media. This can be achieved through log append-only writing or incremental block storage technology, aiming to ensure the reliability and rapid recovery capability of state data.

[0061] In detail, the incremental session manager creates a context container when a diagnostic session starts and initializes it as a lightweight data structure, thus avoiding the high memory consumption issues of traditional full-scale storage mechanisms. The context container only records incremental state changes within the diagnostic session, such as updates to a diagnostic parameter or completion markers for an operation step, rather than a complete state snapshot. This design significantly reduces storage requirements. When the state of the diagnostic session changes, the incremental session manager captures these changes and stores them in the context container. Subsequently, the incremental data is efficiently written to persistent storage through session state persistence. When session state recovery is needed, the system loads the context container based on the latest baseline state and quickly reconstructs the session context using the stored incremental change data. This mechanism not only significantly shortens state recovery time but also effectively reduces the impact of frequent read / write operations on system performance, thus adapting to the resource-constrained environment requirements of automotive diagnostic systems.

[0062] Furthermore, the incremental session manager, along with the context container design and other components that manage the protocol adaptation bus and session context unit, enhances the flexibility and efficiency of the diagnostic system. By focusing on the locality of state changes, this solution optimizes resource utilization while ensuring the integrity of context information, providing low-latency, highly adaptable session management capabilities for on-board diagnostic systems.

[0063] In one embodiment, this application further proposes a management session context unit including an intelligent resource scheduler. The intelligent resource scheduler has a built-in predictive model for predicting resource demand based on historical load data and issuing dynamic scaling (such as creating or destroying service instance containers) and load migration instructions to the service instance layer.

[0064] Specifically, an intelligent resource scheduler is a resource management component with adaptive capabilities, which can be implemented using predictive models based on machine learning algorithms. In practical applications, the predictive model can generate accurate predictions of future resource demands by analyzing the time-series characteristics, periodic patterns, and sudden load patterns of historical load data. The purpose of introducing an intelligent resource scheduler is to solve the problem of uneven resource allocation when diagnosing load fluctuations, thereby improving the overall efficiency and stability of the system.

[0065] In detail, the intelligent resource scheduler uses a built-in predictive model to perform in-depth analysis of historical load data, enabling it to identify and diagnose load trends in advance. For example, before a peak diagnostic period, the predictive model can infer potential resource gaps based on historical data and proactively trigger a dynamic scaling mechanism. At this time, the intelligent resource scheduler sends instructions to the service instance layer to increase the number of service instances to meet the upcoming high load demand. Simultaneously, during periods of low load, the scheduler can reduce the number of service instances to avoid resource idleness and waste. Furthermore, the intelligent resource scheduler can achieve load balancing among service instances through load migration instructions. When it detects that some service instances are overloaded, the scheduler will migrate some of the load to other idle or low-load service instances, thereby preventing local node overload and ensuring the stable operation of the entire diagnostic system.

[0066] In the above scheme, the intelligent resource scheduler works in conjunction with other components in the management session context unit to form a highly efficient resource management system. For example, the incremental session manager is responsible for maintaining the state information of the diagnostic session, while the intelligent resource scheduler dynamically adjusts resource allocation based on this state information to ensure the smoothness of diagnostic operations. This design not only optimizes resource utilization but also significantly improves the system's ability to handle complex diagnostic tasks, demonstrating the integrity and innovation of the technical solution.

[0067] In one embodiment, this application further proposes a management session context unit including an adaptive data conversion pipeline, which consists of a series of pluggable modular conversion components (such as data verification components, format conversion components, encryption components, etc.). The pipeline assembler dynamically combines several modular conversion components into a processing chain according to data characteristics to perform verification, format conversion, or encryption processing on the data flowing through it.

[0068] Specifically, an adaptive data transformation pipeline refers to a data processing mechanism that can automatically adjust its internal processing logic based on the characteristics of the input data. It can be implemented using rule engines, machine learning models, or predefined strategy libraries. Modular transformation components are processing units with independent functions that can be flexibly replaced. These can be components that execute specific data verification algorithms, implement specific format conversion logic, or provide encryption / decryption functions. The pipeline assembler is a control unit responsible for analyzing data characteristics and dynamically assembling appropriate transformation components. It can select and combine components by parsing data header information, protocol identifiers, or content patterns.

[0069] In detail, this solution achieves efficient adaptation of the diagnostic system to dynamic environments through an adaptive data conversion pipeline. Modular conversion components serve as basic processing units, each of which can be independently developed, tested, and replaced. This design significantly improves the system's maintainability and reusability. The pipeline assembler dynamically selects and assembles the optimal conversion component chain based on real-time data characteristics, enabling the system to adapt to different diagnostic scenarios, such as switching from CAN bus to the DoIP protocol without recoding. In the dynamically constructed processing chain, each component sequentially verifies the data to identify anomalies and prevent error propagation, performs format conversion to adapt to different protocol standards for seamless interoperability, and dynamically adjusts the security level based on data sensitivity for encryption processing, thereby ensuring reliable transmission and efficient processing of diagnostic data in complex environments.

[0070] The above technical solutions effectively solve the problem of lack of flexibility and adaptability in data conversion and processing in traditional architectures, and realize the adaptive capability of the diagnostic system when facing different vehicle communication protocols, data formats or diagnostic scenarios, significantly reducing the workload of system porting and maintenance.

[0071] The system architecture of this invention simplifies the diagnostic workflow as follows: When the "Fault Code Query" service in the "Diagnostic Core Unit" needs to be executed, it no longer directly calls any DOIP or Android-related code. Instead, it sends a standard-formatted abstract request, such as readDataByIdentifier(VIN), to the protocol adapter bus. Upon receiving the request, the bus routes it to the registered "DOIP Protocol Adapter" based on the current system configuration. This adapter converts the abstract request into a specific DOIP message and sends it to the vehicle network via the "Android JAR package" interface. The vehicle response returns along the reverse path, is parsed and encapsulated by the protocol adapter, and then the final result data is returned to the "Fault Code Query" service via the bus. By introducing the protocol adapter bus as a core component, this invention reconstructs the traditional vertically tightly coupled architecture into a horizontal, bus-based loosely coupled architecture, achieving physical and logical separation between business functions and communication implementations.

[0072] In one embodiment, this application further proposes a diagnostic method based on the above-described decoupling of the functional layer and protocol parsing layer in an on-board diagnostic system architecture, such as... Figure 3 As shown, the detailed implementation steps are as follows: Step 1: Receive Diagnostic Intent Request: The protocol adapter group receives a declarative diagnostic request submitted by the functional service unit group (client) via the protocol adaptation bus.

[0073] The request data is in JSON format and contains the following key fields: intent_type: Diagnostic intent type (e.g., "Read ECU data", "Diagnose fault").

[0074] target_component: Identifier of the target component (e.g., "engine control unit").

[0075] Parameters: Diagnostic parameters (such as data identifiers, sampling frequency).

[0076] constraints: execution constraints (such as maximum execution time, privacy level).

[0077] This step enables declarative interaction, where the functional service unit group only needs to express what it wants, without specifying how to achieve it.

[0078] Step 2, Analyze diagnostic intent: Transform the abstract diagnostic intent into a specific sequence of diagnostic operations.

[0079] The process analyzes the intent type and target component in the request, and performs semantic understanding in conjunction with the current session context (vehicle status, user permissions) to generate an ordered sequence of diagnostic operations. Each operation includes: an operation identifier, specific parameters, execution preconditions, and expected output format. This step enables intelligent conversion from business intent to technical operation, improving system flexibility.

[0080] Step 3: Match diagnostic capabilities: Match appropriate diagnostic capabilities to the diagnostic operation sequence.

[0081] Specifically, this includes: querying the diagnostic capability registry to find capabilities that support the target operation; negotiating capabilities to ensure the requested operation is available in the system; selecting the best capabilities based on contextual constraints (such as vehicle model and protocol support); and generating a negotiated and confirmed list of executable operations. This step enables dynamic capability discovery and adaptation, supporting system evolution and expansion.

[0082] Step 4: Perform diagnostic operations: Perform diagnostic operations according to the diagnostic operation sequence and obtain raw diagnostic data.

[0083] Specifically, this includes: executing each diagnostic step sequentially according to the operation sequence, calling the corresponding protocol adapter (such as DOIP or CAN protocol adapter), communicating with the vehicle's electronic control unit, and collecting raw diagnostic data and processing status information. This step achieves transparent invocation of specific diagnostic protocols, decoupling business logic from protocol implementation.

[0084] Step 5: Encapsulate semantic response: Transform the raw diagnostic data into semantically rich response data.

[0085] Specifically, this includes: analyzing the quality metrics of the raw data (confidence level, accuracy, timeliness), extracting the semantic meaning of the data based on the original intent, and constructing a semantic response containing the following information: standardized data values, data units and types, quality assessment metrics, data source information, and relevant contextual information. This step provides self-describing intelligent data, facilitating understanding and subsequent processing.

[0086] Step 6: Return the complete diagnostic results (response data) to the functional service unit group.

[0087] This includes encapsulating semantic responses into a standard format, updating session context state, returning results to the client through a standard interface, and logging the diagnostic process for auditing and analysis. This step provides a complete and traceable diagnostic service experience.

[0088] The entire diagnostic process described above involves managing the session context, which means maintaining and managing context information throughout the diagnostic process. Specifically, this includes: creating a session context at the beginning of the diagnostic phase, transmitting and updating context information at each stage, adjusting diagnostic strategies based on context information, and recording a complete diagnostic history for subsequent analysis. This operation enables context-aware intelligent diagnosis, improving diagnostic accuracy and adaptability. Specific Implementation Taking the "read engine speed" diagnostic task as an example, the specific implementation of each step is explained: Request Received: The client sends {"intent": "read_ecu_data", "target": "engine", "parameters": {"data_id": "rpm"}}.

[0090] Analysis intent: The system recognizes this as a request to read ECU data, targeting the engine, and requires obtaining RPM data.

[0091] Matching capability: Find diagnostic capabilities that support reading engine speed and confirm the use of the DOIP protocol.

[0092] Execution: Send a request to read the engine speed to the engine ECU via the DOIP protocol and receive the raw response data [0x12, 0x34].

[0093] Encapsulating the response: Converting raw bytes into a semantic response. / / Core data field: the specific value currently collected; "value": 4660; / / Unit field: Defines the unit of measurement for "value" to ensure unambiguous data interpretation; "unit": "rpm", / / rpm = Revolutions Per Minute, which is the standard unit of measurement for engine speed; / / Semantic annotation fields: Clarify the business meaning of data and avoid confusion caused by the same value having different meanings; "semantic_meaning": "engine_rotation_speed", / / Literally translated as "engine rotation speed", used to identify that this data belongs to the business indicator of "engine rotation speed"; / / Data quality assessment module: describes the reliability and timeliness of the data, supporting downstream judgments on data credibility; "quality_metrics": { "confidence": 0.95, / / Data confidence level (0-1 range): 0.95 indicates that the acquisition accuracy / confidence of the rotational speed data is extremely high (e.g., no sensor interference, no packet loss during transmission); "freshness": "2024-01-20T10:30:00Z" / / Data freshness (ISO 8601 standard time): Indicates the latest update time of the data, used to determine whether the data is "real-time" (this field is important in scenarios such as real-time vehicle monitoring). / / Data traceability module: Records the source and generation time of data for problem tracing (such as locating the source when data is abnormal); "provenance": { "source": "ecu_direct_reading", / / Data source: ecu = Engine Control Unit, indicating that the speed data is read directly from the engine ECU (not indirectly calculated or forwarded by a third party, so the data is more authoritative); "timestamp": "2024-01-20T10:30:00Z" / / Data generation time: consistent with "freshness" (this is a real-time collection scenario). If the data has been cached / forwarded, this time will be earlier than "freshness".

[0094] Return result: The above semantic response will be returned to the client.

[0095] 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.

[0096] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device 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, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.

[0097] These computer program instructions may also be loaded onto a computer or other programmable data processing equipment to cause a series of operational steps to be performed on the computer or other programmable equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable equipment 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.

[0098] 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. An on-board diagnostic system architecture with decoupled functional layer and protocol parsing layer, characterized in that: include The functional service unit group is used to send abstract diagnostic requests to the protocol adaptation bus when performing diagnostic operations; Protocol adapter group, used to perform diagnostic operations based on abstract diagnostic requests and send semantically encapsulated response data to the protocol adaptation bus; The protocol adaptation bus connects the functional service unit group and the protocol adapter group, and is used to transmit abstract diagnostic request and response data to the protocol adapter group and the functional service unit group respectively, thereby decoupling the functional layer from the protocol parsing layer.

2. The on-board diagnostic system architecture with decoupled functional layer and protocol parsing layer as described in claim 1, characterized in that: The functional service unit group includes at least one of the following: tool interaction unit, file processing unit, diagnostic core unit, and control execution unit; The tool interaction unit is used to carry the front-end interaction logic of configuration tools, diagnostic tools, process tools, and full vehicle diagnostics; The file processing unit is used to parse and process XML, PDX configuration files, and software upgrade packages; The diagnostic core unit is used to provide diagnostic services, logistics information query, fault code query and real-time data display. The control execution unit is used to perform control, routine control, special process driving, and controller upgrades.

3. The on-board diagnostic system architecture with decoupled functional layer and protocol parsing layer as described in claim 1, characterized in that: The protocol adapter group includes a protocol parsing module and a platform interface library; The protocol parsing module is used to convert abstract diagnostic requests into specific diagnostic operation sequences, match appropriate diagnostic capabilities to the diagnostic operation sequences, and finally form protocol messages that conform to vehicle communication protocol standards; it is also used to semantically encapsulate raw diagnostic data and convert it into semantically rich response data. The platform interface library is an access interface for connecting to the vehicle network. It is used to send protocol messages to the vehicle network and transmit the raw diagnostic data returned by the vehicle network to the protocol parsing module.

4. The on-board diagnostic system architecture with decoupled functional layer and protocol parsing layer as described in claim 3, characterized in that: The protocol parsing module includes a protocol adaptation matrix and several different protocol adapters connected to the protocol adaptation matrix; The protocol adaptation matrix internally encapsulates a protocol feature description library and a protocol conversion mapping rule library, which are used to receive the registration information of the protocol adapter and send abstract diagnostic requests to the protocol adapter. The protocol adapter is used to convert abstract diagnostic requests into protocol messages that conform to the vehicle communication protocol standard.

5. The on-board diagnostic system architecture with decoupled functional layer and protocol parsing layer as described in claim 1, characterized in that: The protocol adaptation bus is configured with standardized interface specifications for registering protocol adapters and routing abstract diagnostic requests.

6. The on-board diagnostic system architecture with decoupled functional layer and protocol parsing layer as described in claim 1, characterized in that: It also includes a session context management unit, which is used to maintain and manage context information during the diagnostic process.

7. The on-board diagnostic system architecture with decoupled functional layer and protocol parsing layer as described in claim 6, characterized in that: The management session context unit includes 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 combinational logic. The service governance engine is used to receive diagnostic requests sent by the protocol parsing module and perform service parsing and matching based on the diagnostic service capability graph.

8. The on-board diagnostic system architecture with decoupled functional layer and protocol parsing layer as described in claim 6, characterized in that: The management session context unit includes a context-aware router, which is connected to a vehicle status sensor, a system resource monitor, and a service policy library. It is used to acquire multi-dimensional context information including vehicle status, system resources, and service policies, and to execute a routing decision algorithm based on the acquired information to output the optimal service instance and protocol path.

9. The on-board diagnostic system architecture with decoupled functional layer and protocol parsing layer as described in claim 6, characterized in that: The management session context unit includes an incremental session manager, which is used to create and manage context containers for diagnostic sessions. The context container is a lightweight data structure used to store incremental state changes of the diagnostic session and to save and restore the state through persistent session state storage.

10. A diagnostic method for an on-board diagnostic system architecture based on the decoupling of the functional layer and protocol parsing layer as described in claim 1, characterized in that: Receive abstract diagnostic requests sent by the functional service unit group; Transform abstract diagnostic intentions into a specific sequence of diagnostic operations; Match appropriate diagnostic capabilities to the diagnostic procedure sequence; Perform diagnostic operations according to the diagnostic operation sequence and obtain raw diagnostic data; Transform raw diagnostic data into semantically rich response data; Send response data to the functional service unit group.

Images