A non-adaptive platform diagnostic system and method

Abstract

The application discloses a non-adaptive platform diagnosis system and method, relates to the technical field of Internet of Vehicles, and discloses a non-adaptive platform diagnosis system, which comprises a non-adaptive platform and an adaptive platform, wherein the non-adaptive platform and the adaptive platform are connected in communication through inter-process communication; the non-adaptive platform is used for sending a diagnosis request to the adaptive platform; the adaptive platform is used for acquiring a diagnosis-related process of the non-adaptive platform, responding to the diagnosis request according to the diagnosis-related process, and generating response information; and the adaptive platform is further used for diagnosing according to the response information and sending diagnosis results to the non-adaptive platform. The application sends a diagnosis request from the non-adaptive platform to the adaptive platform, the adaptive platform acquires a diagnosis-related process and performs diagnosis, and thus the technical effects of improving vehicle maintenance efficiency and reducing maintenance cost are achieved.

Description

Technical Field

[0001] This application relates to the field of vehicle networking technology, and in particular to a diagnostic system and method for a non-adaptive platform. Background Technology

[0002] Intelligentization, connectivity, and electrification are the future development trends of automobiles. The classic open system architecture platform (AUTomotive Open System Architecture Classic Platform, Autosar CP) can no longer meet the needs of highly complex and computationally demanding applications. Therefore, the adaptive open system architecture platform (AUTomotive Open System Architecture Adaptive Platform, Autosar AP) has emerged.

[0003] In the AP platform, there are diagnostic event managers and diagnostic communication managers responsible for diagnostics. Since the Autosar AP system is developed based on the C++ framework, if engineering software that has been adapted to non-AP platforms needs to be ported to the Autosar AP system for operation, and if diagnostic functions need to be implemented for the corresponding processes of such engineering software, then the code framework needs to be restructured, the code rewritten, and the related dynamic libraries need to be recompiled, which results in a large amount of code modification and high integration difficulty. Summary of the Invention

[0004] The main objective of this application is to provide a diagnostic system and method for non-adaptive platforms, aiming to solve the technical problems of large code modification and high integration difficulty when diagnosing the software of adaptive platforms on automotive open system architecture adaptive platforms.

[0005] To achieve the above objectives, this application proposes a diagnostic system for a non-adaptive platform, which includes a non-adaptive platform and an adaptive platform, wherein the non-adaptive platform and the adaptive platform are connected via inter-process communication.

[0006] The non-adaptive platform is used to send diagnostic requests to the adaptive platform;

[0007] The adaptive platform is used to obtain the diagnosis-related processes of the non-adaptive platform, respond to the diagnosis request according to the diagnosis-related processes, and generate response information.

[0008] The adaptive platform is also used to perform a diagnosis based on the response information and send the diagnosis result to the non-adaptive platform.

[0009] In one embodiment, the adaptive platform further includes a diagnostic agent module and a diagnostic module, wherein the diagnostic agent module and the diagnostic module are connected via inter-process communication.

[0010] The non-adaptive platform is used to send diagnostic requests to the diagnostic agent module;

[0011] The diagnostic agent module is used to obtain diagnostic information data from the diagnostic request, process the diagnostic information data, and obtain diagnostic data.

[0012] The diagnostic agent module is also used to send the diagnostic data to the diagnostic module;

[0013] The diagnostic module is used to perform a diagnosis based on the diagnostic information data and return the diagnostic results to the diagnostic agent module.

[0014] In one embodiment, the diagnostic agent module is further configured to identify the format of the diagnostic information data in the diagnostic request and verify the integrity of the diagnostic information data;

[0015] The diagnostic proxy module is also used to parse the request header of the diagnostic information data and extract the parameters of the diagnostic information data when the integrity of the diagnostic information data is verified.

[0016] The diagnostic agent module is also used to verify the parameters, and when the verification is successful, send the parameters as the response information to the diagnostic module.

[0017] In one embodiment, the diagnostic agent module is further configured to generate a reason for the abnormal integrity of the diagnostic information data when the verification of the integrity of the diagnostic information data fails;

[0018] The diagnostic agent module is also used to send the cause to the non-adaptive platform according to the application programming interface of the reported event.

[0019] In one embodiment, the diagnostic agent module is further configured to process the response information according to the application programming interface of the diagnostic function to obtain diagnostic information data;

[0020] The diagnostic agent module is also used to send the diagnostic information data to the diagnostic module;

[0021] The diagnostic agent module is also used to send the diagnostic results to the non-adaptive platform according to the application programming interface of the reported event.

[0022] Furthermore, to achieve the above objectives, this application also proposes a diagnostic method for a non-adaptive platform. The method is applied to a diagnostic system for a non-adaptive platform, the system comprising: a non-adaptive platform and an adaptive platform. The method includes:

[0023] The non-adaptive platform and the adaptive platform are connected via inter-process communication; the method includes:

[0024] The non-adaptive platform sends a diagnostic request to the adaptive platform;

[0025] The adaptive platform obtains the diagnosis-related processes of the non-adaptive platform, responds to the diagnosis request according to the diagnosis-related processes, and generates response information;

[0026] The adaptive platform performs a diagnosis based on the response information and sends the diagnosis result to the non-adaptive platform.

[0027] In one embodiment, the adaptive platform further includes a diagnostic agent module and a diagnostic module, wherein the diagnostic agent module and the diagnostic module are connected via inter-process communication, and the step of the adaptive platform performing diagnosis based on the response information further includes;

[0028] The non-adaptive platform sends a diagnostic request to the diagnostic agent module;

[0029] The diagnostic agent module obtains diagnostic information data from the diagnostic request, processes the diagnostic information data, and obtains diagnostic data.

[0030] The diagnostic agent module sends the diagnostic data to the diagnostic module;

[0031] The diagnostic module performs a diagnosis based on the diagnostic information data and returns the diagnostic results to the diagnostic agent module.

[0032] In one embodiment, the step of the adaptive platform responding to the diagnostic request and generating response information includes:

[0033] The diagnostic agent module is also used to identify the format of the diagnostic information data in the diagnostic request and verify the integrity of the diagnostic information data.

[0034] When the diagnostic agent module verifies the integrity of the diagnostic information data, it is used to parse the request header of the diagnostic information data and extract the parameters of the diagnostic information data.

[0035] The diagnostic agent module verifies the parameters, and when the verification is successful, sends the parameters as the response information to the diagnostic module.

[0036] In one embodiment, the diagnostic agent module is further configured to identify the format of the diagnostic information data in the diagnostic request, and after the step of verifying the integrity of the diagnostic information data, the module further includes:

[0037] When the diagnostic agent module fails to verify the integrity of the diagnostic information data, it generates a reason for the abnormal integrity of the diagnostic information data.

[0038] The diagnostic agent module sends the cause to the non-adaptive platform according to the application programming interface of the reported event.

[0039] In one embodiment, the step of the adaptive platform performing a diagnosis based on the response information and sending the diagnosis result to the non-adaptive platform includes:

[0040] The diagnostic agent module processes the response information according to the application programming interface of the diagnostic function to obtain diagnostic information data.

[0041] The diagnostic agent module sends the diagnostic information data to the diagnostic module;

[0042] The diagnostic agent module sends the diagnostic results to the non-adaptive platform according to the application programming interface of the reported event.

[0043] One or more technical solutions proposed in this application have at least the following technical effects:

[0044] By introducing an inter-process communication mechanism between the non-adaptive and adaptive platforms, and utilizing a diagnostic agent module to efficiently manage and process diagnostic information data, the accuracy and completeness of diagnostic information are ensured through the format recognition, integrity verification, parameter extraction, and verification techniques of the diagnostic agent module, thereby improving diagnostic reliability. Simultaneously, through application programming interface (API) calls, efficient processing of response information and automation of fault diagnosis are achieved, reducing the workload of code modification and integration with existing engineering software. This solves the problems of large code modification requirements and high integration difficulty in diagnosing non-AP software on the Autosar AP platform in existing technologies. Compared with existing technologies, the technical solution of this application achieves rapid and accurate diagnosis of non-AP software on the Autosar AP platform, improving diagnostic efficiency, reducing technical implementation costs, and enhancing system compatibility and scalability. Attached Figure Description

[0045] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application.

[0046] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, for those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0047] Figure 1 This is a structural block diagram of the first embodiment of the diagnostic system for the non-adaptive platform of this application;

[0048] Figure 2 for Figure 2 This is a structural block diagram of the second embodiment of the diagnostic system for the non-adaptive platform of this application;

[0049] Figure 3 This is a flowchart illustrating the first embodiment of the diagnostic method for a non-adaptive platform according to this application.

[0050] Figure 4 This is a flowchart illustrating the second embodiment of the diagnostic method for a non-adaptive platform according to this application;

[0051] Figure 5 This is an overall architecture diagram of the diagnostic method for a non-adaptive platform in the embodiments of this application.

[0052] The purpose, features, and advantages of this application will be further explained in conjunction with the embodiments and with reference to the accompanying drawings. Detailed Implementation

[0053] It should be understood that the specific embodiments described herein are merely illustrative of the technical solutions of this application and are not intended to limit this application.

[0054] To better understand the technical solution of this application, a detailed description will be provided below in conjunction with the accompanying drawings and specific implementation methods.

[0055] Reference Figure 1 , Figure 1 This is a structural block diagram of the first embodiment of the diagnostic system for the non-adaptive platform of this application.

[0056] like Figure 1 As shown, the diagnostic system for the non-adaptive platform includes a non-adaptive platform 10 and an adaptive platform 20, which are connected via inter-process communication.

[0057] In this embodiment, the non-adaptive platform is used to send a diagnostic request to the adaptive platform;

[0058] It's important to note that the Autosar AP platform is a highly flexible and scalable automotive software architecture that allows complex software components to run on different hardware platforms within a vehicle. The Autosar AP system is designed to meet the needs of future automotive development, such as intelligence, connectivity, and electrification.

[0059] Additionally, it should be noted that a non-adaptive platform is a concept relative to an adaptive platform. In this embodiment, a non-adaptive platform can be an x86 or ARM platform, which are general-purpose computing platforms commonly used in personal computers, servers, and some embedded systems. x86 is a 32-bit and 64-bit microprocessor architecture based on Intel architecture, while ARM is another widely used 32-bit and 64-bit processor architecture. In the automotive field, these platforms may be used to implement certain control units or infotainment systems in vehicles.

[0060] As is understandable, a diagnostic request refers to a diagnostic request issued by software on a non-adaptive platform to that platform. The software on the non-adaptive platform is running on an x86 or ARM platform and may require diagnostics to detect and resolve potential problems. The diagnostic request is issued by this software, requesting the adaptive platform to perform specific diagnostic operations.

[0061] In practical implementation, sending a diagnostic request can be as follows: Assume a car is equipped with an Advanced Driver Assistance System (ADAS) based on an x86 platform. This system monitors the vehicle's surroundings and provides collision warnings. If a camera sensor in the ADAS detects a deterioration in image input quality, possibly due to dirt, damage, or other reasons, it will automatically send a diagnostic request to the Adaptive Platform (Autosar AP). Based on this diagnostic request, the Adaptive Platform will inform the ADAS system or a repair technician of the necessary actions, such as cleaning the camera, replacing the sensor, or updating the software. This process of sending diagnostic requests ensures the reliability and safety of the vehicle's systems.

[0062] Additionally, it is understood that inter-process communication (IPC) is a mechanism that allows different processes or systems to exchange data. In this embodiment, the non-adaptive platform and the adaptive platform establish a communication connection through inter-process communication. This communication connection process may involve using shared memory, message queues, sockets, or other IPC technologies to exchange diagnostic request and response information.

[0063] In this embodiment, the adaptive platform is used to obtain the diagnosis-related processes of the non-adaptive platform, respond to the diagnosis request according to the diagnosis-related processes, and generate response information;

[0064] It should be noted that diagnostic-related processes refer to software processes running on non-adaptive platforms that are related to diagnostic requests. These processes are associated with certain functions or subsystems of the vehicle and require diagnostics to ensure proper operation. For example, an engine control unit (ECU) based on an x86 platform might contain a process responsible for monitoring and controlling the engine's operating status.

[0065] Understandably, acquiring diagnostic-related processes means that the adaptive platform needs to be able to identify and access diagnostic-related processes on the non-adaptive platform.

[0066] Additionally, it should be noted that response information refers to the relevant parameters identified after processing the diagnostic-related information in the diagnostic request and provided to the diagnostic process. The content in the diagnostic request can be diagnosed through the response information, which may include fault codes, sensor readings, system status, or other diagnostic parameters.

[0067] In this embodiment, the adaptive platform is further configured to perform a diagnosis based on the response information and send the diagnosis result to the non-adaptive platform.

[0068] It should be noted that the diagnostic result is generated by the adaptive platform based on the response information and diagnostic process. This diagnostic result may be a fault report, a system status assessment, or a maintenance recommendation.

[0069] Understandably, once a diagnostic result is obtained, the adaptive platform needs to send this information back to the non-adaptive platform. In this embodiment, this step is implemented via the IPC protocol, ensuring that the non-adaptive platform can receive and potentially display or record these results.

[0070] In this embodiment, the adaptive platform further includes a diagnostic agent module and a diagnostic module, wherein the diagnostic agent module and the diagnostic module are connected via inter-process communication.

[0071] It should be noted that the diagnostic agent module is a software component running on the adaptive platform, acting as an intermediary between the non-adaptive and adaptive platforms. Its main function is to receive diagnostic requests from the non-adaptive platform, process these requests, and communicate with the diagnostic module of the adaptive platform.

[0072] Additionally, it's important to note that the diagnostic module is another crucial component of the adaptive platform, responsible for executing the actual diagnostic operations. The diagnostic module may include a series of test programs, a fault code parser, performance monitoring tools, etc. In this embodiment, the diagnostic module typically includes a DEM (Diagnostic Event Manager) and a DCM (Diagnostic Communication Manager), which are responsible for executing specific diagnostic logic and communicating with external diagnostic tools. The DEM manages and responds to diagnostic events, such as logging fault events and triggering diagnostic tests. The DCM handles tasks related to diagnostic communication, such as communicating with external diagnostic tools and executing diagnostic commands.

[0073] In this embodiment, the non-adaptive platform is used to send a diagnostic request to the diagnostic agent module;

[0074] Understandably, when a non-adaptive platform detects a situation requiring diagnostics, such as a decline in system performance or the detection of abnormal signals, it will generate a diagnostic request. This request may contain fault detection information, performance monitoring data, sensor readings, or other parameters related to the vehicle's state. For example, if the engine management system (EMS) detects an anomaly, it may send a diagnostic request containing engine fault codes.

[0075] In this embodiment, the diagnostic agent module is used to obtain diagnostic information data from the diagnostic request, process the diagnostic information data, and obtain diagnostic data.

[0076] It is understandable that acquiring diagnostic information data refers to the diagnostic agent module extracting relevant diagnostic information data from diagnostic requests received from the non-adaptive platform. This data may include fault symptoms, sensor readings, performance indicators, or other parameters related to the vehicle's condition.

[0077] In practical implementation, suppose an engine control unit (ECU) on a non-adaptive platform detects an anomaly, such as a sustained increase in engine temperature. A diagnostic request is generated, containing the following information: Fault symptom: Engine overheating. Sensor reading: Current engine temperature 105°C. Performance indicator: Engine coolant flow rate is below normal. Upon receiving this request, the diagnostic agent module performs the following steps: Parse the request: Identify the fault symptom and related data in the request. Verify completeness: Confirm that all necessary information is included, such as engine temperature and coolant flow rate. Parameter extraction: Extract key parameters, such as the engine temperature value (105°C). Data conversion: If the adaptive platform uses a different temperature unit, convert Celsius to Fahrenheit. Data cleaning: Verify the accuracy of the data and remove any possible redundant information. Generate diagnostic data: Integrate the fault symptom, key parameters, and performance indicators to generate a refined set of diagnostic data.

[0078] In this embodiment, the diagnostic agent module is further configured to send the diagnostic data to the diagnostic module;

[0079] Understandably, the diagnostic agent module passes the generated diagnostic data to the diagnostic module on the adaptive platform for more in-depth analysis and processing.

[0080] Additionally, it's understandable that data transfer between the diagnostic agent module and the diagnostic module is typically achieved through an IPC mechanism. This IPC mechanism can be shared memory, message queues, sockets, or other inter-process data exchange technologies.

[0081] In this embodiment, the diagnostic module is used to perform a diagnosis based on the diagnostic information data and return the diagnostic result to the diagnostic agent module.

[0082] It should be noted that the diagnostic results are derived by the diagnostic module based on the diagnostic information data analysis. The results may include fault codes, system status, recommended maintenance operations, or further diagnostic steps.

[0083] Understandably, the diagnostic module uses diagnostic information data received from the diagnostic agent module to perform diagnostics. This may include analyzing data to identify fault modes, executing fault detection algorithms, querying the fault code database, etc.

[0084] In practice, a control unit (such as an ABS system) on a non-adaptive platform detects an anomaly and sends a diagnostic request to the diagnostic agent module. The diagnostic agent module parses the request, extracts key parameters (such as sensor faults), and generates diagnostic data. This data is then sent to the diagnostic modules (DEM and DCM) via IPC. The DEM records events based on the received diagnostic data and may trigger specific diagnostic tests. The DCM uses this data to communicate with external diagnostic tools to perform more in-depth diagnostic analysis. After completing the diagnosis, the diagnostic modules (DEM and DCM) send the diagnostic results (such as the cause of the fault and recommended repair measures) back to the diagnostic agent module.

[0085] In this embodiment, the diagnostic agent module is also used to process the response information according to the application programming interface of the diagnostic function to obtain diagnostic information data;

[0086] It's important to note that the Application Programming Interface (API) for diagnostic functions is a set of predefined software functions and protocols that encapsulate specific diagnostic operations and data processing capabilities. Using the API for diagnostic functions, developers can build software that interacts with the vehicle's diagnostic system without needing to delve into the details of underlying communication and data processing, thus simplifying the development process and improving software compatibility and maintainability.

[0087] In practice, a non-adaptive platform (such as an x86-based ECU) detects a potential fault and sends a diagnostic request to the adaptive platform. The adaptive platform's diagnostic modules (DEM and DCM) receive the request, perform diagnostic operations, and send preliminary response information back to the diagnostic agent module. The diagnostic agent module processes this response information using the diagnostic function's API. For example, if the response information contains raw sensor data, the API may include a function to convert this data into a more understandable format or calculate specific parameters. The processed diagnostic information data, such as confirmed fault codes, system status assessments, or recommended maintenance actions, is compiled and prepared for transmission to the non-adaptive platform or display to the user.

[0088] In this embodiment, the diagnostic agent module is further configured to send the diagnostic information data to the diagnostic module;

[0089] Understandably, the diagnostic agent module sends the processed diagnostic information data to the diagnostic module for further analysis or storage.

[0090] In this embodiment, the diagnostic agent module is further configured to send the diagnostic results to the non-adaptive platform according to the application programming interface of the reported event.

[0091] It should be noted that the application programming interface (API) for reporting events defines how to collect, format, and transmit event data, typically used to ensure that different systems or components can understand and respond to these events. In vehicle diagnostic systems, the API for reporting events is specifically used to transmit diagnostic events and results, such as fault detection and system state changes, from the adaptive platform back to the non-adaptive platform or other relevant systems, thereby enabling transparent information sharing, fault notification, and appropriate response measures.

[0092] In practice, a control unit on a non-adaptive platform, such as the engine control unit, detects an anomaly and sends a diagnostic request to the adaptive platform. The diagnostic agent module receives the request and forwards it to the diagnostic module of the adaptive platform. The diagnostic module performs the necessary diagnostic operations and generates diagnostic results. The diagnostic agent module receives these results and sends them back to the non-adaptive platform using an event reporting API. For example, if the diagnostic results indicate an engine overheating problem, the diagnostic agent module sends this information back to the engine control unit to display a warning or take other preventative measures.

[0093] Based on the first embodiment of the diagnostic system for a non-adaptive platform of this application, a second embodiment of the diagnostic system for a non-adaptive platform of this application is proposed. In this second embodiment, content that is the same as or similar to that in the first embodiment of the diagnostic system for a non-adaptive platform described above can be referred to the above description and will not be repeated hereafter. Based on this, please refer to... Figure 2 , Figure 2 This is a structural block diagram of the second embodiment of the diagnostic system for the non-adaptive platform of this application.

[0094] like Figure 2 As shown, the diagnostic system for the non-adaptive platform includes a non-adaptive platform 10 and an adaptive platform 20. The adaptive platform 20 includes a diagnostic agent module 21 and a diagnostic module 22. The non-adaptive platform 10 and the diagnostic agent module 21, as well as the diagnostic agent module 21 and the diagnostic module 22, are all connected via inter-process communication.

[0095] In this embodiment, the diagnostic agent module is also used to identify the format of the diagnostic information data in the diagnostic request and verify the integrity of the diagnostic information data;

[0096] It should be noted that the format of diagnostic information data in a diagnostic request refers to the data structure and encoding method. In vehicle diagnostics, data may exist in different formats; for example, sensor readings may be encoded in binary, ASCII, or a specific protocol format.

[0097] Understandably, the diagnostic agent module needs to be able to identify the format of the received data to ensure that the data can be correctly parsed and understood. For example, if the data is sent according to the CAN (Controller Area Network) protocol, the diagnostic agent module needs to be able to identify and parse the data according to this protocol.

[0098] Furthermore, it is understandable that the integrity of diagnostic information data refers to whether the data is complete and accurate, and whether it has been damaged or lost during transmission. Integrity verification is an important step in ensuring data reliability.

[0099] Understandably, methods for checking data integrity include, but are not limited to: checking whether the data packet contains a predefined checksum or checksum, such as CRC (Cyclic Redundancy Check). This is a common error detection method that can detect whether data has changed during transmission. If the data is transmitted in multiple packets, check whether the packet sequence numbers are consecutive to ensure that all data packets have been received without loss. If the data packet contains a timestamp, verify that the timestamp is within a reasonable time range; this helps determine whether the data is up-to-date and has not been delayed or duplicated during transmission. Confirm that the length of the received data packet meets expectations; an incorrect length may indicate that the data has been truncated or over-extended. If the data is transmitted encrypted, decrypt the data using the correct key and ensure that the decrypted data matches expectations.

[0100] In practice: The diagnostic agent module first checks if the data packets contain the correct CRC checksum, calculates the CRC of the received data, and compares it with the checksum in the data packets. Then, it checks the sequence number of the data packets to ensure that all expected data packets have been received in the correct order. Next, the agent module may check the timestamp of each data packet to ensure that the data is up-to-date and there are no duplicates. The agent module may also perform length verification on the data packets to ensure that no data has been truncated or incorrectly padded. If the data is encrypted, the agent module will decrypt it using the appropriate key and check whether the decrypted data conforms to the expected format.

[0101] In this embodiment, the diagnostic agent module is further configured to parse the request header of the diagnostic information data and extract the parameters of the diagnostic information data when the integrity of the diagnostic information data is verified to be passed;

[0102] It should be noted that the request header is a part of the data packet, which usually contains metadata about the data request, such as the request identifier, source address, destination address, transport protocol information, etc.

[0103] Understandably, extracting useful parameters from the request header is crucial for the subsequent diagnostic process. These parameters may include fault codes, sensor identifiers, and the type of diagnostic service requested.

[0104] In the actual implementation process, once the integrity verification is passed, the diagnostic agent module begins to parse the request header and extract key parameters from it, such as the fault code "P0301" (indicating engine misfire) and the sensor ID "Sensor1".

[0105] In this embodiment, the diagnostic agent module is further configured to verify the parameters, and when the verification is successful, send the parameters as the response information to the diagnostic module.

[0106] Understandably, after extracting the parameters, the diagnostic agent module needs to verify their validity. Verification may include checking whether the parameter values ​​are within the expected range, conform to a predefined format, and are compatible with the requested diagnostic service. Once the parameters pass verification, the diagnostic agent module encapsulates these parameters in a response message and sends it to the adaptive platform's diagnostic module for subsequent diagnostic processing.

[0107] In this embodiment, the diagnostic agent module is also used to generate a reason for the abnormal integrity of the diagnostic information data when the verification of the integrity of the diagnostic information data fails.

[0108] It should be noted that "diagnostic information data integrity failure" refers to a situation where data integrity verification fails, which may be caused by various reasons, such as data transmission errors, storage errors, or intentional tampering.

[0109] Understandably, the diagnostic agent module needs to identify and log the reasons for data integrity verification failures. This typically involves checking for issues discovered during the verification process, such as checksum mismatches, missing data packets, or formatting errors. Once the cause of the anomaly is identified, the diagnostic agent module will generate a report containing this information. The report may include the anomaly type, the time of discovery, and the data affected.

[0110] In this embodiment, the diagnostic agent module is further configured to send the cause to the non-adaptive platform according to the application programming interface of the reported event.

[0111] In practice, the non-adaptive platform sent a diagnostic request containing engine sensor data, but the data was affected during transmission for some reason. The diagnostic agent module, during integrity verification, discovered a mismatch between the data's CRC checksum and the actual calculated checksum, indicating potential data corruption. The agent module identified this as the cause of the integrity anomaly and generated an anomaly report, which might state "CRC check failed; data may have been corrupted during transmission."

[0112] Furthermore, referring to Figure 3 , Figure 3 This is a flowchart illustrating the first embodiment of the diagnostic method for a non-adaptive platform according to this application. The diagnostic method for a non-adaptive platform is applied to a diagnostic method system for a non-adaptive platform. The diagnostic method system for a non-adaptive platform includes: a non-adaptive platform and an adaptive platform, wherein the non-adaptive platform and the adaptive platform are connected via inter-process communication. The diagnostic method for a non-adaptive platform includes steps S10 to S30:

[0113] Step S10: The non-adaptive platform sends a diagnostic request to the adaptive platform;

[0114] It's important to note that the Autosar AP platform is a highly flexible and scalable automotive software architecture that allows complex software components to run on different hardware platforms within a vehicle. The Autosar AP system is designed to meet the needs of future automotive development, such as intelligence, connectivity, and electrification.

[0115] Additionally, it should be noted that a non-adaptive platform is a concept relative to an adaptive platform. In this embodiment, a non-adaptive platform can be an x86 or ARM platform, which are general-purpose computing platforms commonly used in personal computers, servers, and some embedded systems. x86 is a 32-bit and 64-bit microprocessor architecture based on Intel architecture, while ARM is another widely used 32-bit and 64-bit processor architecture. In the automotive field, these platforms may be used to implement certain control units or infotainment systems in vehicles.

[0116] As is understandable, a diagnostic request refers to a diagnostic request issued by software on a non-adaptive platform to that platform. The software on the non-adaptive platform is running on an x86 or ARM platform and may require diagnostics to detect and resolve potential problems. The diagnostic request is issued by this software, requesting the adaptive platform to perform specific diagnostic operations.

[0117] In practical implementation, sending a diagnostic request can be as follows: Assume a car is equipped with an Advanced Driver Assistance System (ADAS) based on an x86 platform. This system monitors the vehicle's surroundings and provides collision warnings. If a camera sensor in the ADAS detects a deterioration in image input quality, possibly due to dirt, damage, or other reasons, it will automatically send a diagnostic request to the Adaptive Platform (Autosar AP). Based on this diagnostic request, the Adaptive Platform will inform the ADAS system or a repair technician of the necessary actions, such as cleaning the camera, replacing the sensor, or updating the software. This process of sending diagnostic requests ensures the reliability and safety of the vehicle's systems.

[0118] Additionally, it is understood that inter-process communication (IPC) is a mechanism that allows different processes or systems to exchange data. In this embodiment, the non-adaptive platform and the adaptive platform establish a communication connection through inter-process communication. This communication connection process may involve using shared memory, message queues, sockets, or other IPC technologies to exchange diagnostic request and response information.

[0119] Step S20: The adaptive platform obtains the diagnosis-related processes of the non-adaptive platform, responds to the diagnosis request according to the diagnosis-related processes, and generates response information;

[0120] It should be noted that diagnostic-related processes refer to software processes running on non-adaptive platforms that are related to diagnostic requests. These processes are associated with certain functions or subsystems of the vehicle and require diagnostics to ensure proper operation. For example, an engine control unit (ECU) based on an x86 platform might contain a process responsible for monitoring and controlling the engine's operating status.

[0121] Understandably, acquiring diagnostic-related processes means that the adaptive platform needs to be able to identify and access diagnostic-related processes on the non-adaptive platform.

[0122] Additionally, it should be noted that response information refers to the relevant parameters identified after processing the diagnostic-related information in the diagnostic request and provided to the diagnostic process. The content in the diagnostic request can be diagnosed through the response information, which may include fault codes, sensor readings, system status, or other diagnostic parameters.

[0123] In step S30, the adaptive platform performs a diagnosis based on the response information and sends the diagnosis result to the non-adaptive platform.

[0124] It should be noted that the diagnostic result is generated by the adaptive platform based on the response information and diagnostic process. This diagnostic result may be a fault report, a system status assessment, or a maintenance recommendation.

[0125] Understandably, once a diagnostic result is obtained, the adaptive platform needs to send this information back to the non-adaptive platform. In this embodiment, this step is implemented via the IPC protocol, ensuring that the non-adaptive platform can receive and potentially display or record these results.

[0126] In this embodiment, the adaptive platform further includes a diagnostic agent module and a diagnostic module, wherein the diagnostic agent module and the diagnostic module are connected via inter-process communication.

[0127] It should be noted that the diagnostic agent module is a software component running on the adaptive platform, acting as an intermediary between the non-adaptive and adaptive platforms. Its main function is to receive diagnostic requests from the non-adaptive platform, process these requests, and communicate with the diagnostic module of the adaptive platform.

[0128] Additionally, it's important to note that the diagnostic module is another crucial component of the adaptive platform, responsible for executing the actual diagnostic operations. The diagnostic module may include a series of test programs, a fault code parser, performance monitoring tools, etc. In this embodiment, the diagnostic module typically includes a DEM (Diagnostic Event Manager) and a DCM (Diagnostic Communication Manager), which are responsible for executing specific diagnostic logic and communicating with external diagnostic tools. The DEM manages and responds to diagnostic events, such as logging fault events and triggering diagnostic tests. The DCM handles tasks related to diagnostic communication, such as communicating with external diagnostic tools and executing diagnostic commands.

[0129] In one feasible implementation, step S30 may include steps A31 to A34:

[0130] Step A31: The non-adaptive platform sends a diagnostic request to the diagnostic agent module;

[0131] Understandably, when a non-adaptive platform detects a situation requiring diagnostics, such as a decline in system performance or the detection of abnormal signals, it will generate a diagnostic request. This request may contain fault detection information, performance monitoring data, sensor readings, or other parameters related to the vehicle's state. For example, if the engine management system (EMS) detects an anomaly, it may send a diagnostic request containing engine fault codes.

[0132] Step A32: The diagnostic agent module obtains the diagnostic information data in the diagnostic request, processes the diagnostic information data, and obtains diagnostic data.

[0133] It is understandable that acquiring diagnostic information data refers to the diagnostic agent module extracting relevant diagnostic information data from diagnostic requests received from the non-adaptive platform. This data may include fault symptoms, sensor readings, performance indicators, or other parameters related to the vehicle's condition.

[0134] In practical implementation, suppose an engine control unit (ECU) on a non-adaptive platform detects an anomaly, such as a sustained increase in engine temperature. A diagnostic request is generated, containing the following information: Fault symptom: Engine overheating. Sensor reading: Current engine temperature 105°C. Performance indicator: Engine coolant flow rate is below normal. Upon receiving this request, the diagnostic agent module performs the following steps: Parse the request: Identify the fault symptom and related data in the request. Verify completeness: Confirm that all necessary information is included, such as engine temperature and coolant flow rate. Parameter extraction: Extract key parameters, such as the engine temperature value (105°C). Data conversion: If the adaptive platform uses a different temperature unit, convert Celsius to Fahrenheit. Data cleaning: Verify the accuracy of the data and remove any possible redundant information. Generate diagnostic data: Integrate the fault symptom, key parameters, and performance indicators to generate a refined set of diagnostic data.

[0135] Step A33: The diagnostic agent module sends the diagnostic data to the diagnostic module;

[0136] Understandably, the diagnostic agent module passes the generated diagnostic data to the diagnostic module on the adaptive platform for more in-depth analysis and processing.

[0137] Additionally, it's understandable that data transfer between the diagnostic agent module and the diagnostic module is typically achieved through an IPC mechanism. This IPC mechanism can be shared memory, message queues, sockets, or other inter-process data exchange technologies.

[0138] Step A34: The diagnostic module performs a diagnosis based on the diagnostic information data and returns the diagnostic result to the diagnostic agent module.

[0139] It should be noted that the diagnostic results are derived by the diagnostic module based on the diagnostic information data analysis. The results may include fault codes, system status, recommended maintenance operations, or further diagnostic steps.

[0140] Understandably, the diagnostic module uses diagnostic information data received from the diagnostic agent module to perform diagnostics. This may include analyzing data to identify fault modes, executing fault detection algorithms, querying the fault code database, etc.

[0141] In practice, a control unit (such as an ABS system) on a non-adaptive platform detects an anomaly and sends a diagnostic request to the diagnostic agent module. The diagnostic agent module parses the request, extracts key parameters (such as sensor faults), and generates diagnostic data. This data is then sent to the diagnostic modules (DEM and DCM) via IPC. The DEM records events based on the received diagnostic data and may trigger specific diagnostic tests. The DCM uses this data to communicate with external diagnostic tools to perform more in-depth diagnostic analysis. After completing the diagnosis, the diagnostic modules (DEM and DCM) send the diagnostic results (such as the cause of the fault and recommended repair measures) back to the diagnostic agent module.

[0142] In one feasible implementation, step S30 may include steps B31 to B33:

[0143] Step B31: The diagnostic agent module processes the response information according to the application programming interface of the diagnostic function to obtain diagnostic information data;

[0144] It's important to note that the Application Programming Interface (API) for diagnostic functions is a set of predefined software functions and protocols that encapsulate specific diagnostic operations and data processing capabilities. Using the API for diagnostic functions, developers can build software that interacts with the vehicle's diagnostic system without needing to delve into the details of underlying communication and data processing, thus simplifying the development process and improving software compatibility and maintainability.

[0145] In practice, a non-adaptive platform (such as an x86-based ECU) detects a potential fault and sends a diagnostic request to the adaptive platform. The adaptive platform's diagnostic modules (DEM and DCM) receive the request, perform diagnostic operations, and send preliminary response information back to the diagnostic agent module. The diagnostic agent module processes this response information using the diagnostic function's API. For example, if the response information contains raw sensor data, the API may include a function to convert this data into a more understandable format or calculate specific parameters. The processed diagnostic information data, such as confirmed fault codes, system status assessments, or recommended maintenance actions, is compiled and prepared for transmission to the non-adaptive platform or display to the user.

[0146] Step B32: The diagnostic agent module sends the diagnostic information data to the diagnostic module;

[0147] Understandably, the diagnostic agent module sends the processed diagnostic information data to the diagnostic module for further analysis or storage.

[0148] Step B33: The diagnostic agent module sends the diagnostic results to the non-adaptive platform according to the application programming interface of the reported event.

[0149] It should be noted that the application programming interface (API) for reporting events defines how to collect, format, and transmit event data, typically used to ensure that different systems or components can understand and respond to these events. In vehicle diagnostic systems, the API for reporting events is specifically used to transmit diagnostic events and results, such as fault detection and system state changes, from the adaptive platform back to the non-adaptive platform or other relevant systems, thereby enabling transparent information sharing, fault notification, and appropriate response measures.

[0150] In practice, a control unit on a non-adaptive platform, such as the engine control unit, detects an anomaly and sends a diagnostic request to the adaptive platform. The diagnostic agent module receives the request and forwards it to the diagnostic module of the adaptive platform. The diagnostic module performs the necessary diagnostic operations and generates diagnostic results. The diagnostic agent module receives these results and sends them back to the non-adaptive platform using an event reporting API. For example, if the diagnostic results indicate an engine overheating problem, the diagnostic agent module sends this information back to the engine control unit to display a warning or take other preventative measures.

[0151] Based on the first embodiment of the diagnostic method for non-adaptive platforms of this application, a second embodiment of the diagnostic method for non-adaptive platforms of this application is proposed. In this second embodiment, content that is the same as or similar to that in the first embodiment of the diagnostic method for non-adaptive platforms described above can be referred to the above description and will not be repeated hereafter. Based on this, please refer to... Figure 4 , Figure 4 This is a flowchart illustrating the second embodiment of the diagnostic method for a non-adaptive platform according to this application. In this embodiment, step S20 further includes steps S21 to 23:

[0152] Step S21, the diagnostic agent module is further used to identify the format of the diagnostic information data in the diagnostic request and verify the integrity of the diagnostic information data;

[0153] It should be noted that the format of diagnostic information data in a diagnostic request refers to the data structure and encoding method. In vehicle diagnostics, data may exist in different formats; for example, sensor readings may be encoded in binary, ASCII, or a specific protocol format.

[0154] Understandably, the diagnostic agent module needs to be able to identify the format of the received data to ensure that the data can be correctly parsed and understood. For example, if the data is sent according to the CAN (Controller Area Network) protocol, the diagnostic agent module needs to be able to identify and parse the data according to this protocol.

[0155] Furthermore, it is understandable that the integrity of diagnostic information data refers to whether the data is complete and accurate, and whether it has been damaged or lost during transmission. Integrity verification is an important step in ensuring data reliability.

[0156] Understandably, methods for checking data integrity include, but are not limited to: checking whether the data packet contains a predefined checksum or checksum, such as CRC (Cyclic Redundancy Check). This is a common error detection method that can detect whether data has changed during transmission. If the data is transmitted in multiple packets, check whether the packet sequence numbers are consecutive to ensure that all data packets have been received without loss. If the data packet contains a timestamp, verify that the timestamp is within a reasonable time range; this helps determine whether the data is up-to-date and has not been delayed or duplicated during transmission. Confirm that the length of the received data packet meets expectations; an incorrect length may indicate that the data has been truncated or over-extended. If the data is transmitted encrypted, decrypt the data using the correct key and ensure that the decrypted data matches expectations.

[0157] In practice: The diagnostic agent module first checks if the data packets contain the correct CRC checksum, calculates the CRC of the received data, and compares it with the checksum in the data packets. Then, it checks the sequence number of the data packets to ensure that all expected data packets have been received in the correct order. Next, the agent module may check the timestamp of each data packet to ensure that the data is up-to-date and there are no duplicates. The agent module may also perform length verification on the data packets to ensure that no data has been truncated or incorrectly padded. If the data is encrypted, the agent module will decrypt it using the appropriate key and check whether the decrypted data conforms to the expected format.

[0158] Step S22: When the diagnostic agent module verifies the integrity of the diagnostic information data, it parses the request header of the diagnostic information data and extracts the parameters of the diagnostic information data.

[0159] It should be noted that the request header is a part of the data packet, which usually contains metadata about the data request, such as the request identifier, source address, destination address, transport protocol information, etc.

[0160] Understandably, extracting useful parameters from the request header is crucial for the subsequent diagnostic process. These parameters may include fault codes, sensor identifiers, and the type of diagnostic service requested.

[0161] In the actual implementation process, once the integrity verification is passed, the diagnostic agent module begins to parse the request header and extract key parameters from it, such as the fault code "P0301" (indicating engine misfire) and the sensor ID "Sensor1".

[0162] Step S23: The diagnostic agent module verifies the parameter, and when the verification is successful, sends the parameter as the response information to the diagnostic module.

[0163] Understandably, after extracting the parameters, the diagnostic agent module needs to verify their validity. Verification may include checking whether the parameter values ​​are within the expected range, conform to a predefined format, and are compatible with the requested diagnostic service. Once the parameters pass verification, the diagnostic agent module encapsulates these parameters in a response message and sends it to the adaptive platform's diagnostic module for subsequent diagnostic processing.

[0164] In one possible implementation, step S21 may be followed by steps S211 to S212:

[0165] Step S211: When the diagnostic agent module fails to verify the integrity of the diagnostic information data, it generates a reason for the abnormal integrity of the diagnostic information data.

[0166] It should be noted that "diagnostic information data integrity failure" refers to a situation where data integrity verification fails, which may be caused by various reasons, such as data transmission errors, storage errors, or intentional tampering.

[0167] Understandably, the diagnostic agent module needs to identify and log the reasons for data integrity verification failures. This typically involves checking for issues discovered during the verification process, such as checksum mismatches, missing data packets, or formatting errors. Once the cause of the anomaly is identified, the diagnostic agent module will generate a report containing this information. The report may include the anomaly type, the time of discovery, and the data affected.

[0168] In step S212, the diagnostic agent module sends the cause to the non-adaptive platform according to the application programming interface of the reported event.

[0169] In practice, the non-adaptive platform sent a diagnostic request containing engine sensor data, but the data was affected during transmission for some reason. The diagnostic agent module, during integrity verification, discovered a mismatch between the data's CRC checksum and the actual calculated checksum, indicating potential data corruption. The agent module identified this as the cause of the integrity anomaly and generated an anomaly report, which might state "CRC check failed; data may have been corrupted during transmission."

[0170] Reference Figure 5 , Figure 5This diagram illustrates the overall architecture of the diagnostic method for a non-adaptive platform in this application, showcasing the diagnostic interaction process between non-AP platform applications and the Autosar adaptive platform (AP platform). The specific descriptions of each element in the diagram are as follows: AP platform applications: Represent applications conforming to the Autosar AP platform standard, capable of utilizing the AP platform's diagnostic functions. Diagnostic applications refer to diagnostic applications running on the AP platform and conforming to AP platform specifications. APP0, APP1, APP2, APPn: These represent different application instances on the non-AP platform; the numbers 0, 1, 2, and n indicate sequence numbers, signifying multiple applications. The diagnostic agent is a key component, acting as an intermediary between the non-AP platform software and the AP platform, responsible for handling diagnostic requests and responses. DEM stands for Diagnostics Event Manager, responsible for collecting and processing diagnostic events. DCM stands for Diagnostics Communication Manager, used to manage diagnostic communication sessions and service requests. 0x22, 0x2E, 0x36, 0x19: These are hexadecimal numbers representing identifiers for specific diagnostic services or communication sessions. PER refers to the performance evaluator or related components. DOIP Stack: Represents Diagnostic over Internet Protocol Stack, conforming to the ISO 13400 / DoIP standard, used for diagnostic communication at the network layer. SOC: Represents System on Chip, the central processing unit of the vehicle, responsible for coordinating and managing various vehicle functions.

[0171] Non-AP platform software interacts with the AP platform through a diagnostic agent. The diagnostic agent collects diagnostic requests from the non-AP platform software, establishes communication with the SOC via the DOIP Stack, and forwards the requests to the DCM. The DCM further distributes the requests to the corresponding AP platform application or DEM for processing. The processing results are returned to the non-AP platform software through the same path, completing the diagnostic process. The hexadecimal codes in the diagram may represent the identifiers of specific services or requests used in the diagnostic communication process. The entire architecture represents an efficient and standardized diagnostic process for non-adaptive platforms.

[0172] It should be noted that the above examples are only for understanding this application and do not constitute a limitation on the diagnostic method of this non-adaptive platform. Any simple modifications based on this technical concept are within the protection scope of this application.

[0173] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

Claims

1. A diagnostic system for a non-adaptive platform, characterized by, The diagnostic system of the non-adaptive platform comprises a non-adaptive platform and an adaptive platform, wherein the non-adaptive platform and the adaptive platform are connected through inter-process communication; The non-adaptive platform is configured to send a diagnostic request to the adaptive platform; The adaptive platform is configured to acquire a diagnostic related process of the non-adaptive platform, respond to the diagnostic request according to the diagnostic related process, and generate response information; The adaptive platform is further configured to perform diagnosis according to the response information and send a diagnostic result to the non-adaptive platform; The adaptive platform further comprises a diagnostic agent module and a diagnostic module, wherein the diagnostic agent module and the diagnostic module are connected through inter-process communication; The non-adaptive platform is configured to send a diagnostic request to the diagnostic agent module; The diagnostic agent module is configured to acquire diagnostic information data in the diagnostic request, process the diagnostic information data, and obtain diagnostic data; The diagnostic agent module is further configured to send the diagnostic data to the diagnostic module; The diagnostic module is configured to perform diagnosis according to the diagnostic information data and return a diagnostic result of the diagnosis to the diagnostic agent module.

2. The system of claim 1, wherein, The diagnostic agent module is further configured to identify a format of the diagnostic information data in the diagnostic request and verify integrity of the diagnostic information data; When the integrity verification of the diagnostic information data is passed, the diagnostic agent module is further configured to parse a request header of the diagnostic information data and extract parameters of the diagnostic information data; When the parameter verification is passed, the diagnostic agent module is further configured to send the parameters as the response information to the diagnostic module.

3. The system of claim 2, wherein, When the integrity verification of the diagnostic information data is failed, the diagnostic agent module is further configured to generate a cause of the diagnostic information data integrity exception; The diagnostic agent module is further configured to send the cause to the non-adaptive platform according to an application programming interface of a reporting event.

4. The system of claim 1, wherein, The diagnostic agent module is further configured to process the response information according to an application programming interface of a diagnostic function and obtain diagnostic information data; The diagnostic agent module is further configured to send the diagnostic information data to the diagnostic module; The diagnostic agent module is further configured to send the diagnostic result to the non-adaptive platform according to an application programming interface of a reporting event.

5. A diagnostic method for a non-adaptive platform, characterized by, The method is applied to a diagnostic system of a non-adaptive platform, and the system comprises a non-adaptive platform and an adaptive platform, wherein the non-adaptive platform and the adaptive platform are connected through inter-process communication; the method comprises: The non-adaptive platform sends a diagnostic request to the adaptive platform; The adaptive platform acquires a diagnostic related process of the non-adaptive platform, responds to the diagnostic request according to the diagnostic related process, and generates response information; The adaptive platform performs diagnosis according to the response information and sends a diagnostic result to the non-adaptive platform; The adaptive platform further comprises a diagnosis agent module and a diagnosis module, wherein the diagnosis agent module and the diagnosis module are communicatively connected through inter-process communication, and the step of diagnosing by the adaptive platform according to the response information further comprises: The non-adaptive platform sends a diagnosis request to the diagnosis agent module; The diagnosis agent module acquires diagnosis information data in the diagnosis request, processes the diagnosis information data, and obtains diagnosis data; The diagnosis agent module sends the diagnosis data to the diagnosis module; The diagnosis module diagnoses according to the diagnosis information data, and returns a diagnosis result of the diagnosis to the diagnosis agent module.

6. The method of claim 5, wherein, The step of responding to the diagnosis request and generating response information by the adaptive platform comprises: The diagnosis agent module is further configured to identify a format of diagnosis information data in the diagnosis request, and verify integrity of the diagnosis information data; When the verification of the integrity of the diagnosis information data passes, the diagnosis agent module is configured to parse a request header of the diagnosis information data, and extract parameters of the diagnosis information data; The diagnosis agent module verifies the parameters, and when the verification passes, sends the parameters as the response information to the diagnosis module.

7. The method of claim 6, wherein, The step of verifying the integrity of the diagnosis information data further comprises: When the verification of the integrity of the diagnosis information data fails, the diagnosis agent module generates a cause of diagnosis information data integrity exception; The diagnosis agent module sends the cause to the non-adaptive platform according to an application programming interface of a reporting event.

8. The method of claim 5, wherein, The step of diagnosing by the adaptive platform according to the response information, and sending the diagnosis result to the non-adaptive platform comprises: The diagnosis agent module processes the response information according to an application programming interface of a diagnosis function, and obtains diagnosis information data; The diagnosis agent module sends the diagnosis information data to the diagnosis module; The diagnosis agent module sends the diagnosis result to the non-adaptive platform according to an application programming interface of a reporting event.

Images