Vehicle diagnosis method and device, electronic equipment and storage medium

Abstract

The application provides a vehicle diagnosis method and device, electronic equipment and a storage medium. The method comprises the following steps: in the case that a vehicle-side diagnosis instruction is received, determining a diagnosis level corresponding to the vehicle-side diagnosis instruction; determining a diagnosis process corresponding to the vehicle-side diagnosis instruction based on the diagnosis level; and diagnosing the vehicle according to the diagnosis process corresponding to the vehicle-side diagnosis instruction. When the vehicle-side diagnosis instruction is received at the server, the diagnosis level corresponding to the instruction is first determined, and then the corresponding diagnosis process is matched according to the diagnosis level, and finally the diagnosis of the vehicle is completed according to the determined diagnosis process. The overall diagnosis coverage of the vehicle can be realized, the fault positioning accuracy and efficiency are significantly improved, the diagnosis access process is simplified, and the system maintenance cost is reduced.

Description

Technical Field

[0001] This application relates to the field of vehicle diagnostic technology, and in particular to a vehicle diagnostic method, apparatus, electronic device and storage medium. Background Technology

[0002] With the rapid development of intelligent vehicle technology, the number of onboard electronic control units continues to increase, and vehicle operating systems are becoming increasingly complex. The coexistence of multiple operating systems, such as Linux and Android, on the same vehicle platform has become the industry norm. The complexity of onboard software architecture has increased significantly. Current scenarios such as remote after-sales maintenance, real-vehicle fault diagnosis, and automated bench testing all require diagnostic systems to support remote cloud control and real-time acquisition of operational data at all levels, in order to quickly locate deep-seated software faults such as deadlocks and thread blocking.

[0003] Traditional vehicle diagnostics rely on local diagnostic tools, which can only read fault codes and basic controller status, and do not have remote interaction capabilities. Existing remote diagnostic solutions in the industry are based on vehicle diagnostic protocols to build basic reporting channels, which can initially realize data interaction between the cloud and the vehicle, but can only cover coarse-grained process-level monitoring dimensions and cannot achieve comprehensive diagnostic coverage of the entire vehicle. Summary of the Invention

[0004] The purpose of this application is to provide a vehicle diagnostic method, device, electronic device, and storage medium to solve the technical problem that remote diagnostic solutions can only cover coarse-grained process-level monitoring and cannot achieve comprehensive diagnostic coverage of the entire vehicle. The specific technical solution is as follows: In a first aspect of this application, a vehicle diagnostic method is provided, applied to a server, the method comprising: Upon receiving a vehicle-side diagnostic command, determine the diagnostic level corresponding to the vehicle-side diagnostic command; Based on the diagnostic level, the diagnostic process corresponding to the vehicle-side diagnostic command is determined; The vehicle is diagnosed according to the diagnostic process corresponding to the vehicle-side diagnostic command.

[0005] In an optional implementation, determining the diagnostic level corresponding to the vehicle-side diagnostic command includes: The vehicle-side diagnostic command is parsed to obtain command identification information; The diagnostic level corresponding to the vehicle-side diagnostic instruction is determined by querying a preset diagnostic instruction mapping table based on the instruction identifier information.

[0006] In an optional implementation, determining the diagnostic process corresponding to the vehicle-side diagnostic command based on the diagnostic level includes: If the diagnostic level belongs to the first level or the second level, then the diagnostic process is determined to be a local execution process; If the diagnostic level is the third or fourth level, then the diagnostic process is determined to be a remote distribution process. The first level is used to obtain basic information about the controller hardware and operating system; the second level is used to obtain overall system resource usage information; the third level is used to obtain process-level deep running information; and the fourth level is used to obtain thread-level runtime behavior information.

[0007] In an optional implementation, the step of diagnosing the vehicle according to the diagnostic process corresponding to the vehicle-side diagnostic instruction includes: If the diagnostic process is a local execution process, then local system information is collected and diagnostic response data is generated; If the diagnostic process is a remote distribution process, then the registered client process list is queried according to the instruction identifier information in the vehicle-side diagnostic instruction to determine the target client process; the vehicle-side diagnostic instruction is distributed to the target client process, and the diagnostic response data returned by the target client process is received.

[0008] In an optional implementation, the list of registered client processes is generated in the following way: Each client process establishes a communication connection with the server through the client initialization interface; When the server receives a registration request sent by any of the client processes through the registration interface, it obtains the diagnostic instruction identifier information, process identifier information and callback processing information corresponding to the client process from the registration request. The diagnostic instruction identifier information, the process identifier information, and the callback processing information corresponding to the client process are associated and stored to generate the registered client process list.

[0009] In an optional implementation, after obtaining the diagnostic instruction identifier information, process identifier information, and callback processing information corresponding to the client process from the registration request, the method further includes: Based on the process identification information, query the list of registered client processes to see if there is already a registration record for the same client process with the same diagnostic instruction identification information; If it exists, return a registration failure status to the client process; If it does not exist, then determine whether the diagnostic instruction identification information is within a preset valid range; If it is within the preset valid range, then the step of associating and storing the diagnostic instruction identification information supported by the client process, the process identification information and the callback processing information, generating the registered client process list, and returning the registration success status to the client process; If the value exceeds the preset valid range, a registration rejection status is returned to the client process.

[0010] In an optional implementation, the step of distributing the vehicle-side diagnostic command to the target client process and receiving diagnostic response data returned by the target client process includes: Determine the diagnostic distribution model; When the diagnostic distribution mode is asynchronous distribution mode, the asynchronous distribution interface is called to distribute the vehicle-side diagnostic instructions to the target client process, and the diagnostic response data returned by the target client process is received through callback processing information; When the diagnostic distribution mode is synchronous distribution mode, the synchronous distribution interface is called to distribute the vehicle-side diagnostic instructions to the target client process, and the diagnostic response data is received using the inter-process communication channel.

[0011] In an optional implementation, receiving the diagnostic response data via an inter-process communication channel includes: An inter-process communication channel is created, and the read and write ends of the inter-process communication channel are associated with a global wait structure, which is used to store the diagnostic response data. The inter-process communication channel is monitored via a polling interface. After the target client process completes the diagnostic data collection and writes the diagnostic response data into the global wait structure, it writes notification data through the write end of the inter-process communication channel. When the polling interface detects that there is data to read at the read end of the inter-process communication channel, the diagnostic response data is read from the global wait structure.

[0012] In a second aspect of this application, a vehicle diagnostic device is also provided, applied to a server, the device comprising: The diagnostic level determination module is used to determine the diagnostic level corresponding to the vehicle-side diagnostic command when a vehicle-side diagnostic command is received. The diagnostic process determination module is used to determine the diagnostic process corresponding to the vehicle-side diagnostic instruction based on the diagnostic level. The diagnostic module is used to diagnose the vehicle according to the diagnostic process corresponding to the vehicle-side diagnostic instructions.

[0013] In a third aspect of the embodiments of this application, an electronic device is also provided, including a processor, a communication interface, a memory, and a communication bus, wherein the processor, the communication interface, and the memory communicate with each other through the communication bus; Memory, used to store computer programs; The processor, when executing a program stored in memory, implements the vehicle diagnostic method described in any one of the first aspects above.

[0014] In a fourth aspect of the embodiments of this application, a storage medium is also provided, the storage medium storing instructions that, when run on a computer, cause the computer to perform any of the vehicle diagnostic methods described in the first aspect above.

[0015] In a fifth aspect of the embodiments of this application, a computer program product containing instructions is also provided, which, when run on a computer, causes the computer to perform any of the vehicle diagnostic methods described in the first aspect above.

[0016] The technical solution provided in this application determines the diagnostic level corresponding to a vehicle-side diagnostic command upon receiving it; determines the corresponding diagnostic process based on the diagnostic level; and diagnoses the vehicle according to the diagnostic process corresponding to the vehicle-side diagnostic command. This technical solution, by first determining the diagnostic level corresponding to the command when the server receives a vehicle-side diagnostic command, then matching the corresponding diagnostic process based on the diagnostic level, and finally completing the vehicle diagnosis according to the determined diagnostic process, achieves comprehensive diagnostic coverage of the entire vehicle, significantly improves fault location accuracy and efficiency, simplifies the diagnostic access process, and reduces system maintenance costs. Attached Figure Description

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

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

[0019] One or more embodiments are illustrated by way of example with reference numerals in the accompanying drawings. These illustrations do not constitute a limitation on the embodiments. Elements with the same reference numerals in the drawings are denoted as similar elements. Unless otherwise stated, the figures in the drawings are not to be limited by scale.

[0020] Figure 1A schematic diagram illustrating the implementation process of a vehicle diagnostic method provided in this application embodiment; Figure 2 A schematic diagram illustrating the implementation process of a method for determining diagnostic levels provided in this application embodiment; Figure 3 A schematic diagram illustrating the implementation process of a diagnostic procedure determination method provided in this application embodiment; Figure 4 A schematic diagram illustrating the implementation process of another vehicle diagnostic method provided in this application embodiment; Figure 5 This application provides a schematic diagram of a vehicle diagnostic process. Figure 6 This is a schematic diagram of the structure of a vehicle diagnostic device provided in an embodiment of this application; Figure 7 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Detailed Implementation

[0021] To make the objectives, technical solutions, and advantages of the embodiments of this application clearer, the technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0022] The following disclosure provides numerous different embodiments or examples for implementing various structures of this application. To simplify the disclosure, specific examples of components and arrangements are described below. These are merely examples and are not intended to limit the scope of this application. Furthermore, reference numerals and / or letters may be repeated in different examples. Such repetition is for simplification and clarity and does not in itself indicate a relationship between the various embodiments and / or arrangements discussed.

[0023] The vehicle diagnostic method provided in this application will be further explained and described below with reference to the accompanying drawings and specific embodiments. These embodiments do not constitute a limitation on the embodiments of the present invention.

[0024] To address the technical issue that existing remote diagnostic solutions can only cover coarse-grained process-level monitoring and cannot meet the requirement of comprehensive diagnostic coverage for the entire vehicle, this application provides a vehicle diagnostic method. Upon receiving a vehicle-side diagnostic command, the method determines the diagnostic level corresponding to the command; based on the diagnostic level, it determines the diagnostic process corresponding to the command; and then diagnoses the vehicle according to the diagnostic process corresponding to the command.

[0025] This technical solution, upon receiving a diagnostic command from the vehicle, first determines the corresponding diagnostic level, then matches the appropriate diagnostic process based on the level, and finally completes the vehicle diagnosis according to the determined process. It eliminates the need for external diagnostic equipment or manual troubleshooting, achieving comprehensive vehicle diagnostic coverage solely through the collaboration of the vehicle's own server and client processes, significantly reducing the manual and time costs of fault location. Simultaneously, because the diagnostic process automatically adapts to the diagnostic level, diagnostic commands at different levels are accurately distributed to the most suitable execution entity. This avoids overloading the server with unnecessary data collection tasks and enables timely acquisition of process-level and thread-level deep processing data. By providing runtime information, the system effectively solves the problem of root cause analysis difficulties caused by insufficient information collection granularity. Furthermore, by dividing the diagnostic process into a local execution process and a remote distribution process, instructions belonging to the controller hardware layer or system resource layer are directly collected by the server to complete the diagnosis using local system information. Instructions belonging to the process-level deep layer or thread-level runtime behavior layer are distributed to the corresponding target client process for execution by querying the list of registered client processes. This achieves hierarchical processing of diagnostic tasks, which has higher flexibility and scalability compared to traditional diagnostic solutions. As a result, it can achieve comprehensive diagnostic coverage of the entire vehicle, significantly improve fault location accuracy and efficiency, and simplify the diagnostic access process while reducing system maintenance costs.

[0026] like Figure 1 The diagram shown is a schematic representation of the implementation process of a vehicle diagnostic method provided in this application embodiment. Applied to the server side, it may specifically include the following steps: S101, upon receiving a vehicle-side diagnostic command, determines the diagnostic level corresponding to the vehicle-side diagnostic command.

[0027] The aforementioned vehicle-side diagnostic commands refer to command data issued by a cloud server or local host computer to request the vehicle to perform specific diagnostic tasks.

[0028] The aforementioned diagnostic levels refer to the hierarchical classification based on the depth and scope of data requested by the diagnostic command. Each diagnostic level corresponds to a set of preset diagnostic data collection ranges and is associated with a preset diagnostic execution entity type (including execution by the server itself or execution by a specific client process). The diagnostic level guides the server in determining the appropriate process for executing the diagnostic task when it receives a vehicle-side diagnostic command, thereby ensuring that the diagnostic command is routed to the most suitable execution entity. It can include levels one, two, three, and four. The system employs a four-tiered approach: the first tier acquires basic controller hardware and operating system information (such as a list of controller CPUs (Central Processing Units), basic CPU information, operating system list, file system information, software package version list, physical memory information, hard disk size information, and network type information); the second tier acquires overall system resource usage information (such as a process list, memory usage, system interrupt information, CPU core usage, and remaining file system space); the third tier acquires process-level deep runtime information (such as process memory summaries, file descriptor usage counts, thread lists, lock lists, queue lists, and timer lists); and the fourth tier acquires thread-level runtime behavior information (such as thread switching information, thread call stacks, and thread CPU utilization). In this embodiment, upon receiving a vehicle-side diagnostic command, it indicates that a diagnostic task from the cloud or host computer needs to be executed. At this point, it is necessary to determine the diagnostic level corresponding to the vehicle-side diagnostic command so that a suitable execution path and execution entity can be allocated to the command. By defining the diagnostic level, vehicle-side diagnostic requests of different granularities can be classified, avoiding the indiscriminate execution of all vehicle-side diagnostic instructions by the same processing logic, thereby improving diagnostic efficiency.

[0029] As for how the diagnostic level corresponding to the vehicle-side diagnostic command is determined, it can be explained in the following text. Figure 2 The process shown will be explained in detail here.

[0030] S102, based on the diagnostic level, determine the diagnostic process corresponding to the vehicle-side diagnostic command.

[0031] The aforementioned diagnostic process refers to different execution methods adopted for vehicle-side diagnostic commands at different diagnostic levels, which can include local execution and remote distribution processes. The local execution process involves the server process directly collecting local system information and generating diagnostic response data. The remote distribution process involves the server distributing vehicle-side diagnostic commands to registered target client processes via a local inter-process communication channel. The target client processes then collect the diagnostic data and return it to the server. The difference between the local execution and remote distribution processes lies in the entity responsible for collecting the diagnostic data: the local execution process involves the server itself, suitable for diagnostic information that does not require in-depth understanding of a specific process; the remote distribution process involves the client process, suitable for diagnostic tasks that require in-depth understanding of a specific process to obtain thread-level runtime information.

[0032] In this embodiment, the diagnostic process corresponding to the vehicle-side diagnostic command can be determined based on the diagnostic level. This step, by determining the diagnostic process corresponding to the vehicle-side diagnostic command, can route the vehicle-side diagnostic command to the most suitable execution entity (such as execution by the server itself, or the corresponding target client process) according to the diagnostic level.

[0033] As for how the diagnostic process corresponding to the vehicle-side diagnostic commands is determined based on the diagnostic level, it can be explained in the following text. Figure 3 The process shown will be explained in detail here.

[0034] S103, perform vehicle diagnosis according to the diagnostic procedure corresponding to the vehicle-side diagnostic instructions.

[0035] The aforementioned vehicle diagnostics refers to the process of performing corresponding diagnostic operations according to a defined diagnostic procedure, collecting vehicle operation data requested by the vehicle-side diagnostic command, and generating diagnostic response data.

[0036] In this embodiment, the vehicle is diagnosed according to the diagnostic process corresponding to the vehicle-side diagnostic command. This step is used to execute the vehicle-side diagnostic command and generate diagnostic response data that can be parsed by the cloud or host computer, thereby realizing real-time observation and fault location of the entire vehicle. Through the above steps, the vehicle-side diagnostic command can be accurately distributed to the most suitable execution entity, ensuring both the integrity of diagnostic data collection and diagnostic efficiency.

[0037] As for the specific procedures for diagnosing the vehicle according to the diagnostic instructions from the vehicle terminal, these will be explained below. Figure 4 The process shown will be explained in detail here.

[0038] Based on the above description of the technical solution provided in the embodiments of this application, upon receiving a vehicle-side diagnostic instruction, the diagnostic level corresponding to the vehicle-side diagnostic instruction is determined; based on the diagnostic level, the diagnostic process corresponding to the vehicle-side diagnostic instruction is determined; and the vehicle is diagnosed according to the diagnostic process corresponding to the vehicle-side diagnostic instruction.

[0039] This technical solution, upon receiving a diagnostic command from the vehicle, first determines the corresponding diagnostic level, then matches the appropriate diagnostic process based on that level, and finally completes the vehicle diagnosis according to the determined diagnostic process. It eliminates the need for external diagnostic equipment or manual troubleshooting, achieving comprehensive vehicle diagnostic coverage solely through the collaboration of the vehicle's own server and client processes, significantly reducing the manual and time costs of fault location. Simultaneously, because the diagnostic process automatically adapts to the diagnostic level, diagnostic commands at different levels are accurately distributed to the most suitable execution entity, avoiding server overload from unnecessary data collection tasks and enabling timely acquisition of process-level and thread-level data. Deep runtime information effectively solves the problem of root cause analysis difficulties caused by insufficient information collection granularity. Furthermore, by dividing the diagnostic process into a local execution process and a remote distribution process, instructions belonging to the controller hardware layer or system resource layer are directly collected by the server to complete the diagnosis by local system information, while instructions belonging to the process-level deep layer or thread-level runtime behavior layer are distributed to the corresponding target client process for execution by querying the list of registered client processes. This achieves hierarchical processing of diagnostic tasks, which has higher flexibility and scalability than traditional diagnostic solutions. As a result, comprehensive diagnostic coverage of the entire vehicle can be achieved, significantly improving fault location accuracy and efficiency, while simplifying the diagnostic access process and reducing system maintenance costs.

[0040] like Figure 2 The diagram shown is a schematic representation of the implementation flow of a method for determining diagnostic levels according to an embodiment of this application. Figure 2 exist Figure 1 Based on this, a detailed description is provided on how to determine the diagnostic level corresponding to the vehicle-side diagnostic command, which may include the following: S201 parses the vehicle-side diagnostic commands to obtain command identification information.

[0041] In this embodiment, the vehicle-side diagnostic commands can be parsed to obtain command identification information. The command identification information refers to an identifier field used to uniquely identify the type and function of the vehicle-side diagnostic command.

[0042] For example, the vehicle diagnostic command is [0x03][0x01][0x01][0x00], where the first byte 0x03 is the data frame identifier, the next two bytes 0x01 and 0x01 are the command identifier information (RID), and the last byte 0x00 is the diagnostic parameters. After receiving this command, the server parses the vehicle diagnostic command, skips the data frame identifier in the frame header, extracts the command identifier information, and obtains the command identifier information as E101.

[0043] S202, based on the instruction identification information, query the preset diagnostic instruction mapping table to determine the diagnostic level corresponding to the vehicle-side diagnostic instruction.

[0044] In this embodiment, a preset diagnostic instruction mapping table can be queried based on the instruction identifier information to determine the diagnostic level corresponding to the vehicle-side diagnostic instruction. The preset diagnostic instruction mapping table is a data structure pre-stored on the server, recording the correspondence between instruction identifier information, diagnostic level, and diagnostic function description. The preset diagnostic instruction mapping table can be implemented using an array, hash table, key-value pair set, or database table, etc.

[0045] For example, the preset diagnostic instruction mapping table is shown in Table 1: Table 1

[0046] The server can query the preset diagnostic instruction mapping table (i.e., Table 1) based on the instruction identifier information (e.g., E103) parsed in step S201 above. After matching the corresponding table entry record, the server can read the diagnostic level field in the table entry to determine that the diagnostic level corresponding to the vehicle diagnostic instruction is the third level.

[0047] like Figure 3 The diagram shown is a schematic representation of the implementation flow of a diagnostic process determination method provided in an embodiment of this application. Figure 3 exist Figure 1 Building upon this, the paper details how to determine the diagnostic process corresponding to vehicle-side diagnostic commands based on diagnostic levels, which may include the following: S301, if the diagnostic level is either Level 1 or Level 2, then the diagnostic process is determined to be a local execution process. Level 1 is used to obtain basic information about the controller hardware and operating system, while Level 2 is used to obtain overall system resource usage information.

[0048] The aforementioned controller hardware and operating system basic information refers to the hardware configuration information and operating system runtime environment information at the vehicle controller level, including but not limited to: controller CPU list (including the number of CPU cores, clock speed, architecture type, etc.), basic CPU information (such as model, cache size, instruction set support, etc.), operating system list (all operating system types and versions running on the vehicle), file system information on each operating system (such as mount point, file system type, usage rate, etc.), software package version list (core software installed on each operating system and version number), physical memory information (total memory size, used memory, available memory, etc.), hard disk size information (total storage space, used space, remaining space, etc.), and network type information (network interface type, IP (Internet Protocol) address, MAC (Media Access Control Address), network connection status, etc.).

[0049] The aforementioned overall system resource usage information refers to the macroscopic operating status and resource consumption information at the vehicle system level, including but not limited to: process list (names, process identifiers, and statuses of all running processes in the current system), memory usage (the percentage of overall system memory usage), system interrupt information (interrupt vector number, number of interrupts, interrupt distribution of each CPU core, etc.), CPU core usage (the percentage of each CPU core used in user mode, system mode, and idle mode), and file system remaining space information (the remaining storage capacity of each partition).

[0050] In this embodiment, if the diagnostic level is either the first or second level, it indicates that the data requested by the current vehicle-side diagnostic command is macroscopic information about the controller hardware layer and system resource layer. This information can be obtained by the server directly reading system files or calling system APIs through the standard interface provided by the operating system, without needing to delve into specific processes. Therefore, the diagnostic process is determined to be a local execution process, with the server itself completing data collection (i.e., if the diagnostic level is the first level, it collects basic information such as controller hardware and operating system; if the diagnostic level is the second level, it collects information such as overall system resource usage) and generating diagnostic response data. This avoids unnecessary inter-process communication overhead, improves diagnostic response speed, and reduces system complexity.

[0051] S302, if the diagnostic level is the third or fourth level, then the diagnostic process is determined to be a remote distribution process. The third level is used to obtain process-level deep runtime information, and the fourth level is used to obtain thread-level runtime behavior information.

[0052] The aforementioned process-level deep runtime information refers to in-depth data collection on the internal runtime state of a specific process, including but not limited to: process memory summary (process virtual memory size, physical memory resident set size RSS, memory mapping region distribution, etc.), number of file descriptors used (total number and type distribution of currently open file descriptors in the process), thread list (identifiers, names, states, etc. of all threads in the process), lock list (current state of mutexes, read-write locks, etc. used in the process, including the number of lock PV operations and the current owner), queue list (current length and state of message queues, task queues, etc. in the process), and timer list (registered timer numbers, timeouts, callback functions, etc. in the process).

[0053] The aforementioned thread-level runtime behavior information refers to the real-time running behavior data of each thread in a specific process, including but not limited to: thread switching information (the number of context switches for each thread, statistics of voluntary and involuntary switches, etc.), thread call stack (the current execution position of the thread and the function call relationship chain, which can be used to analyze deadlock and thread blocking problems), thread CPU utilization (the proportion of user-mode and system-mode CPU time for each thread), etc.

[0054] In this embodiment, if the diagnostic level is the third or fourth level, it indicates that the data requested by the current vehicle-side diagnostic command is process-level deep information and thread-level runtime behavior information. This information is highly process-specific and thread-specific, and must be collected internally by the target process targeted by the vehicle-side diagnostic command. The server cannot directly obtain it through system-level interfaces. Therefore, the diagnostic process is determined to be a remote distribution process. The server distributes the vehicle-side diagnostic command to the registered target client process through a local inter-process communication channel. The target client process then performs diagnostic data collection through a registered callback function and returns the collection results to the server. The remote distribution process ensures that the diagnostic command is accurately delivered to the target process, and the client process with access permissions and data collection capabilities completes the deep diagnostic task, thereby achieving comprehensive collection of process-level and thread-level runtime states.

[0055] like Figure 4 The diagram shown is a schematic representation of the implementation process of another vehicle diagnostic method provided in this application. Figure 4 exist Figure 1 Based on this, a detailed description is provided on how to diagnose a vehicle according to the diagnostic process corresponding to the vehicle-side diagnostic instructions. Specifically, this may include the following: S401, If ​​the diagnostic process is a local execution process, then collect local system information and generate diagnostic response data.

[0056] In this embodiment of the application, if the diagnostic process is executed locally, local system information is collected to generate diagnostic response data. The local system information may include basic information about the controller hardware and operating system, and overall system resource usage information.

[0057] Specifically, the server can determine the specific data items to be collected based on the instruction identifier information in the diagnostic instructions, and then obtain local system information by calling the standard interface provided by the operating system or by reading system files.

[0058] For example, if the instruction identifier information of the vehicle-side diagnostic instruction is E101 (belonging to the first level), the server collects the basic information of the controller hardware and operating system, and then encapsulates the collected basic information of the controller hardware and operating system according to a preset data format (such as JSON format) to generate diagnostic response data.

[0059] S402, if the diagnostic process is a remote distribution process, then query the list of registered client processes according to the instruction identifier information in the vehicle-side diagnostic instruction to determine the target client process; distribute the vehicle-side diagnostic instruction to the target client process, and receive the diagnostic response data returned by the target client process.

[0060] In this embodiment of the application, if the diagnostic process is a remote distribution process, the registered client process list is queried according to the instruction identifier information in the vehicle diagnostic instruction to determine the target client process; the vehicle diagnostic instruction is distributed to the target client process, and the diagnostic response data returned by the target client process is received.

[0061] For example, if the vehicle diagnostic command's command identifier is E103 (belonging to the third level, used to obtain process-level deep runtime information), the server queries the list of registered client processes, using the command identifier E103 as the key to find a matching entry in the list. The list of registered client processes stores the associations of diagnostic command identifier (RID), process identifier (PID), socket file descriptor (FD), and callback processing information (i.e., callback function pointer) reported by each client process during registration. The server finds a client process registered with RID=E103 (e.g., a business process A, PID=1234, FD=7) and identifies this client process as the target client process. Then, the server performs frame assembly processing on the vehicle diagnostic command: assembling the data frame identifier (0x03), command identifier (E103), and diagnostic parameter data (if any) into a data frame according to the protocol format, and sending the data frame to the target client process through the socket file descriptor FD=7 corresponding to the target client process. Meanwhile, the server determines the distribution mode based on whether the DoipHandler callback handling information registered during initialization is NULL: if DoipHandler is not NULL, the asynchronous distribution mode is used, and the asynchronous distribution interface (Vos_DiagnosisCommand_Distribute_Async) is called and returned immediately, waiting for the client process to return data through the callback function; if DoipHandler is NULL, the synchronous distribution mode is used, and the synchronous distribution interface (Vos_DiagnosisCommand_Distribute_Sync) is called, waiting for response data until data is received or a timeout occurs (the timeout period is, for example, 2 seconds).

[0062] It should be noted that after receiving a data frame from the server, the target client process (PID=1234) first determines the data type based on the frame identifier in the frame header. If the data frame starts with 0x03, it is identified as a diagnostic instruction data frame. The target client process then disassembles the data frame, extracting the instruction identifier information (E103) and diagnostic parameter data. Next, based on the extracted RID=E103, the client process searches for the corresponding callback processing information (such as the callback function pointer RegCmdHandle) in its own registered callback function list. Once found, it calls the corresponding callback function to perform the diagnostic data acquisition operation. The callback function performs specific diagnostic data collection: it iterates through the process's memory-mapped regions to obtain a process memory summary (total virtual memory size, RSS resident set size, permissions and offsets of each memory-mapped region, etc.), obtains file descriptor usage (number of open file descriptors, file type and path pointed to by each FD), obtains a thread list (TID, name, and status of each thread), queries the process's lock management module to obtain lock status information (current PV operation count for each lock, lock owner thread ID, waiter queue length, etc.), queries the process's queue management module to obtain a queue list and status (current length, maximum length, enqueue / dequeue rate, etc.), and queries the process's timer management module to obtain a timer list and status. After collection, the client process encapsulates all the collected data into response data in JSON format, adds RID=E103 and a sequence number (seq_no) to the response data, assembles it, and sends it back to the server.

[0063] As an optional embodiment, distributing vehicle-side diagnostic commands to the target client process and receiving diagnostic response data returned by the target client process may specifically include the following steps: Step 11, determine the diagnostic distribution mode.

[0064] In this embodiment, a diagnostic distribution mode is determined. The diagnostic distribution mode refers to the method by which the server distributes diagnostic instructions to the target client process and then obtains diagnostic response data. This can include asynchronous distribution mode and synchronous distribution mode. In asynchronous distribution mode, the server returns immediately after calling the distribution interface without blocking and waiting for response data. After the target client process completes the collection of diagnostic data, it actively pushes the response data to the server through a callback function. In synchronous distribution mode, the server blocks and waits after calling the distribution interface until it receives diagnostic response data returned by the target client process or a timeout occurs before continuing subsequent operations.

[0065] Specifically, the diagnostic dispatch mode can be determined by checking whether the callback function pointer DoipHandler passed during server initialization is null. If the callback function pointer DoipHandler is not null, the diagnostic dispatch mode is determined to be asynchronous; if the callback function pointer DoipHandler is null, the diagnostic dispatch mode is determined to be synchronous.

[0066] Step 12: When the diagnostic distribution mode is asynchronous, call the asynchronous distribution interface to distribute the vehicle-side diagnostic instructions to the target client process, and receive the diagnostic response data returned by the target client process through callback processing information.

[0067] In this embodiment, when the diagnostic distribution mode is asynchronous, the asynchronous distribution interface is called to distribute the vehicle-side diagnostic command to the target client process, and the diagnostic response data returned by the target client process is received through callback processing information. The asynchronous distribution interface refers to an interface function that returns to the caller immediately after sending the diagnostic command to the target client process without blocking or waiting, such as the Vos_DiagnosisCommand_Distribute_Async interface. The callback processing information refers to a DoipPthreadCallback type function pointer registered during the server initialization phase. When the target client process completes diagnostic data collection and returns the response data to the server, the server actively pushes the diagnostic response data to the caller process, such as the DoIP Server or Perfmonitor, through this callback function.

[0068] Specifically, in asynchronous distribution mode, after receiving the vehicle diagnostic command from the cloud, the server can call the asynchronous distribution interface (Vos_DiagnosisCommand_Distribute_Async). If it is a query action that can be executed by the server (such as the vehicle diagnostic commands corresponding to E101 and E102), the server directly collects local system information and returns all data in JSON format through the callback function DoipPthreadCallback passed during initialization. If it is a diagnostic command that needs to be sent to other client processes (such as the diagnostic commands corresponding to E103 and E104), the server looks up the corresponding registered client socket file descriptor FD according to the passed command identifier information RID, assembles the RID and sequence number (seq_no) in front of the data, sends it to the client process, and sets a 2-second timeout. Upon receiving a message starting with a data frame (0x03), the corresponding client process decomposes the data to obtain the RID, locates the corresponding callback function RegCmdHandle, passes the diagnostic parameter data sent from the cloud to it, and sends the response data, along with the corresponding RID and sequence number, to the server. Upon receiving the data frame, the server returns all data in JSON format via the callback function DoipPthreadCallback. If no notification is received within 2 seconds, an empty response ({}) is returned, indicating failure.

[0069] Step 13: When the diagnostic distribution mode is synchronous distribution mode, call the synchronous distribution interface to distribute the vehicle-side diagnostic instructions to the target client process, and use the inter-process communication channel to receive diagnostic response data.

[0070] In this embodiment, when the diagnostic distribution mode is synchronous distribution mode, the synchronous distribution interface is called to distribute the vehicle-side diagnostic command to the target client process, and the diagnostic response data is received using the inter-process communication channel. The synchronous distribution interface refers to an interface function that blocks and waits after sending the diagnostic command to the target client process until diagnostic response data is received or a timeout occurs before returning, such as the Vos_DiagnosisCommand_Distribute_Sync interface. The inter-process communication channel refers to a mechanism used for inter-process communication, such as a pipe mechanism, to achieve synchronous waiting.

[0071] Specifically, a fixed-size array can be used to manage the global wait structure for multiple concurrent vehicle diagnostic requests, assigning a unique sequence number (seq_no) to each vehicle diagnostic request. When multiple client processes concurrently initiate vehicle diagnostic requests, the diagnostic response data corresponding to different vehicle diagnostic requests is distinguished according to the sequence number, preventing data overwriting and corruption.

[0072] In synchronous distribution mode, after the server calls the synchronous distribution interface to distribute diagnostic instructions to the target client process, it can call the read end of the inter-process communication channel to block and wait, setting a timeout (e.g., 2 seconds). When the target client process completes the collection of diagnostic data and returns the response data to the server, the server writes the response data to the global wait structure, and then writes one byte of notification data through the write end of the inter-process communication channel. Upon detecting that data is available to read on the read end of the inter-process communication channel, the server immediately returns. The server reads the diagnostic response data from the global wait structure, copies the data in JSON format to the fourth parameter (recv_data, i.e., the received data buffer) of the synchronous distribution interface, and assigns the valid data length to the fifth parameter (recv_length, i.e., the address of the received data length). The synchronous distribution interface returns success. If no notification data is received from the write end of the inter-process communication channel within the timeout period (e.g., 2 seconds), poll times out and returns. The synchronous distribution interface determines that a timeout has occurred and returns an empty response ({}).

[0073] As an optional implementation, receiving diagnostic response data using an inter-process communication (IPC) channel can specifically include: creating an IPC channel and associating its read and write ends with a global wait structure, which stores the diagnostic response data. The IPC channel's read end is monitored via a polling interface. When the target client process completes diagnostic data collection and writes the diagnostic response data to the global wait structure, notification data is written via the IPC channel's write end. When the polling interface detects that data is available to read on the IPC channel's read end, the diagnostic response data is read from the global wait structure.

[0074] The read end of the aforementioned inter-process communication channel is used to read data from the inter-process communication channel.

[0075] The write end of the aforementioned inter-process communication channel is used to write data (i.e., diagnostic response data) to the inter-process communication channel.

[0076] The aforementioned global wait structure is used to store status information and diagnostic response data during the synchronization wait process. The global wait structure can at least include: a data buffer (data_buf, used to store diagnostic response data returned by the target client process), a data length (data_len, used to record the actual length of the received response data), a wait flag (waiting, a boolean type, used to indicate whether a synchronization request is currently waiting for a response), a file descriptor for the inter-process communication channel's read end (pipe_read_fd), and a file descriptor for the inter-process communication channel's write end (pipe_write_fd).

[0077] Specifically, the server can assign the file descriptors corresponding to the read end and the write end obtained after creating the inter-process communication channel to the corresponding members of the global wait structure, thereby associating the read end and write end of the inter-process communication channel with the global wait structure.

[0078] It should be noted that the above list of registered client processes can be generated in the following way: Step 21: Each client process establishes a communication connection with the server through the client initialization interface.

[0079] In this embodiment, each client process can establish a communication connection with the server through a client initialization interface. The client initialization interface refers to the interface function used to initialize the diagnostic module and establish a communication connection with the server as a client, such as the Vos_DiagnosisCommand_Init interface.

[0080] Furthermore, the prototype of the Vos_DiagnosisCommand_Init interface is bool Vos_DiagnosisCommand_Init(bool is_server, DoipPthreadCallback DoipHandler). The first parameter, is_server, is a boolean type used to identify the role of the process currently calling the interface: when is_server is true, it indicates that the current process is running as a server; when is_server is false, it indicates that the current process is running as a client. The second parameter, DoipHandler, is a pointer to a callback function of type DoipPthreadCallback, used to receive diagnostic response data in asynchronous dispatch mode. When this parameter is not NULL, it indicates that asynchronous dispatch mode is used; when it is NULL, it indicates that synchronous dispatch mode is used.

[0081] For the client process, it can complete the client initialization of the diagnostic module by calling this interface at startup and passing in is_server=false and DoipHandler=NULL.

[0082] For example, when business process A starts, it calls `Vos_DiagnosisCommand_Init(false, NULL)`. Internally, this creates a Unix domain socket and connects to the server's socket address ` / socket / diagnosis`. After a successful connection, the server records the client's file descriptor `FD=7`. At this point, business process A has completed the client initialization of the diagnostic module and established a communication connection with the server. Subsequently, it can call the registration interface (`Vos_DiagnosisCommand_Reg`) to register the diagnostic commands it supports with the server.

[0083] Step 22: When the server receives a registration request sent by any client process through the registration interface, it obtains the diagnostic instruction identifier information, process identifier information and callback processing information corresponding to the client process from the registration request.

[0084] In this embodiment, when the server receives a registration request sent by any client process through the registration interface, it can obtain the diagnostic instruction identifier information, process identifier information, and callback processing information corresponding to the client process from the registration request. The registration interface refers to the interface function used by the client process to register its diagnostic capabilities with the server, such as the Vos_DiagnosisCommand_Reg interface. The process identifier information is used to distinguish different client processes. The socket file descriptor refers to the communication identifier used to establish a communication connection between the server and the client process.

[0085] Furthermore, the prototype of the Vos_DiagnosisCommand_Reg interface is: typedef bool (*RegCmdHandle)(const uint8_t* diag_data, uint32_t diag_len, uint8_t* response_data, uint32_t* response_len). Here, diag_data is a pointer to the diagnostic command parameter data buffer, diag_len is the length of the diagnostic command parameter data, response_data is a pointer to the response data buffer, and response_len is the address of the response data length (it needs to be assigned the maximum length of the response buffer before calling, and updated to the actual length of the response data upon return). When the client process receives a diagnostic command distributed by the server, it calls this callback function to perform the specific diagnostic data collection operation and returns the collected diagnostic response data through response_data and response_len. When the client process calls the registration interface, it can assemble its supported diagnostic command identification information (rid), process identification information (PID), and corresponding callback processing information (cmd_cb) according to a preset protocol format to generate a registration request data frame.

[0086] Specifically, the header of the registration request data frame is the registration frame identifier (0x04), used to distinguish whether the data frame is a registration request or a regular diagnostic data frame from the server. Following the header are the diagnostic instruction identifier (rid, 2 bytes), process identifier (PID, 4 bytes), CPU serial number (1 byte), operating system serial number (1 byte), and callback processing information (cmd_cb). The callback processing information itself is not directly transmitted in the data frame; instead, the server uses this pointer to access it within the client process's address space. The client only needs to include information such as rid and PID in the registration request. After receiving the registration request, the server records the callback processing information based on the client process context corresponding to the connection. The client process then sends the assembled registration request data frame to the server through the established Unix domain socket connection.

[0087] After receiving a data frame from a client process, the server first reads the first byte of the frame header to determine the data type: if the first byte is a registration frame identifier (0x04), the data frame is determined to be a registration request; if the first byte is a data frame identifier (0x03), the data frame is determined to be a diagnostic data frame. Once a registration request is identified, the server further extracts the diagnostic instruction identifier (rid) and process identifier (PID) from the data frame, and retrieves the callback processing information (cmd_cb, a pointer passed as a parameter when the client calls the Vos_DiagnosisCommand_Reg interface and stored locally by the client process) from the connection context corresponding to the client process. After obtaining the diagnostic instruction identifier (rid), process identifier (PID), and callback processing information (cmd_cb) corresponding to the client process from the registration request, the server associates and stores this information, along with the socket file descriptor (FD) corresponding to the client process, in the registration management list, thereby generating or updating the list of registered client processes.

[0088] It should be noted that during data transmission, the data frame header distinguishes between registration frames and data frames. The data frame identifier is 0x03, used to transmit diagnostic commands and diagnostic response data. After receiving a data frame from the client process, the server first reads the first byte of the frame header to determine the data type: if the first byte is the registration frame identifier (0x04), the data frame is determined to be a registration request; if the first byte is the data frame identifier (0x03), the data frame is determined to be a diagnostic data frame.

[0089] In addition, after obtaining the diagnostic instruction identifier information, process identifier information, and callback processing information corresponding to the client process from the registration request, the following steps may also be included: Step 221: Based on the process identifier information, query the list of registered client processes to see if there is already a registration record for the same client process with the same diagnostic instruction identifier information.

[0090] In this embodiment of the application, the process identification information can be used to query whether there is already a registration record of the same client process with the same diagnostic instruction identification information in the list of registered client processes.

[0091] Specifically, the server can use process identifier information as a query condition to search the list of registered client processes for a registration record with the same diagnostic instruction identifier information.

[0092] Step 222: If the registration fails, return a registration failure status to the client process.

[0093] In this embodiment, if the diagnostic instruction identifier information already exists, it indicates that the client process has already successfully registered the diagnostic instruction identifier information. The current registration request is a duplicate registration. Allowing duplicate registration would lead to routing ambiguity during subsequent diagnostic instruction distribution, meaning the server would be unable to determine which registration record's processing entry point to distribute the diagnostic instruction to. To avoid this problem, the server needs to return a registration failure status to the client process, informing it that the diagnostic instruction identifier information has been registered twice and this registration request is rejected.

[0094] Step 223: If it does not exist, determine whether the diagnostic instruction identifier information is within the preset valid range.

[0095] In this embodiment, if the diagnostic command identifier information does not exist, it indicates that the client process has not previously registered the diagnostic command identifier information, and the current registration request is a legitimate new registration request. At this time, the server can further determine whether the diagnostic command identifier information is within a preset valid range. The preset valid range refers to a predefined and supported range or set of numerical values ​​for all compliant diagnostic command identifier information. For example, the preset valid range is defined as E101 to E199, meaning that all diagnostic command identifier information greater than or equal to E101 and less than or equal to E199 are valid values ​​supported by the system; identifiers outside this range (such as E200 and above or E100 and below) are considered invalid. The preset valid range can be flexibly configured and expanded according to the actual types of diagnostic commands supported by the system. For example, when the system adds diagnostic functions such as E105 and E106, only the newly added `rid` needs to be included in the preset valid range; there is no need to modify the core registration logic.

[0096] Step 224: If it is within the preset valid range, then execute the step of associating and storing the diagnostic instruction identification information, process identification information and callback processing information supported by the client process, generating a list of registered client processes, and returning a registration success status to the client process.

[0097] In this embodiment of the application, if it is within the preset valid range, it means that the diagnostic instruction identification information is a legal identifier supported by the system. Therefore, the step of associating and storing the diagnostic instruction identification information, process identification information and callback processing information supported by the client process to generate a list of registered client processes can be executed, namely step 23, and the registration success status is returned to the client process.

[0098] Step 225: If the registration is rejected, return a registration rejection status to the client process.

[0099] In this embodiment of the application, if the diagnostic instruction identification information is outside the preset valid range, it means that the diagnostic instruction identification information is not within the set of legal identifiers supported by the system, and the diagnostic command corresponding to the diagnostic instruction identification information cannot be identified and processed. Therefore, it is necessary to return a registration rejection status to the client process.

[0100] In another embodiment of this application, client registration may further include a retry mechanism. That is, after sending a registration request, the client process waits for a registration confirmation frame from the server for a set timeout period (e.g., 50 milliseconds). If no registration confirmation frame is received within the timeout period, the registration request is re-initiated until the maximum number of retries (e.g., 5 times) is reached. If registration still fails after reaching the maximum number of retries, the connection between the client process and the server is closed. This retry mechanism effectively addresses registration failures caused by network jitter or temporary server overload, improving the reliability of the registration process.

[0101] Step 23: Associate and store the diagnostic instruction identifier information, process identifier information and callback processing information corresponding to the client process to generate a list of registered client processes.

[0102] In this embodiment, the diagnostic instruction identifier information, process identifier information and callback function pointer corresponding to the client process can be associated and stored to generate a list of registered client processes.

[0103] Furthermore, the vehicle diagnostic method provided in this application is illustrated with specific examples in the embodiments of this application: like Figure 5 The diagram illustrates a vehicle diagnostic process according to an embodiment of this application. This vehicle diagnostic process is applied to a vehicle diagnostic system. The vehicle diagnostic system adopts a server-client architecture. The server-side process (such as Perfmonitor) is responsible for receiving diagnostic commands from the cloud or host computer and routing them to the most appropriate execution entity based on their diagnostic level. Client-side processes (such as various business processes) report their supported diagnostic capabilities to the server through a registration interface and, upon receiving diagnostic commands distributed by the server, perform specific data acquisition operations and return the acquisition results to the server. Local inter-process communication connections are established between the server and each client process via Unix domain sockets.

[0104] I. System initialization phase, which includes two parts: server initialization and client initialization.

[0105] Server Initialization: When the server process (e.g., Perfmonitor) starts, it calls the diagnostic module initialization interface `Vos_DiagnosisCommand_Init(true, DoipHandler)`. The first parameter, set to `true`, initializes the current process as a server. The second parameter is a callback function pointer, `DoipHandler`. A non-NULL second parameter indicates asynchronous dispatch mode, while a NULL parameter indicates synchronous dispatch mode. This callback function is used to receive diagnostic response data returned by the client in asynchronous dispatch mode. After server initialization, the server internally starts a receiving thread, creates a Unix domain socket, and binds it to a preset socket address (e.g., ` / socket / diagnosis`). The receiving thread then listens for connection requests from clients.

[0106] Client Initialization: Each client process (e.g., business process A, business process B) calls the diagnostic module initialization interface Vos_DiagnosisCommand_Init(false, NULL) upon startup. The first parameter is set to false to indicate that the current process is running as a client, and the second parameter is always NULL. Internally, the interface creates a Unix domain socket and attempts to connect to the server's preset socket address. If the connection fails, the client closes. Upon successful connection, the operating system allocates a file descriptor (FD) for the connection, and the client starts a receiving thread. The client process completes the initialization of the diagnostic module, establishes a communication connection with the server, and can subsequently register its supported diagnostic commands with the server through the registration interface.

[0107] II. Client Registration Process.

[0108] After the client process completes initialization, it needs to report its supported diagnostic capabilities to the server through the registration interface. The registration process includes the following steps: Step 1: The client generates a registration request. The client process calls the registration interface Vos_DiagnosisCommand_Reg(rid, identity_info, handler), where rid is the diagnostic command identifier supported by the client (e.g., E103), identity_info carries identity information, and handler is a pointer to the callback function corresponding to the diagnostic command identifier. The client assembles the diagnostic command identifier (RID), process PID, and other identity information into a packet according to a preset protocol format, generating a registration request data frame. The header of the registration request data frame is a registration frame identifier (0x04), used by the server to distinguish whether the data frame is a registration request or a regular diagnostic data frame.

[0109] Step 2: The client sends a registration request. The client's receiving thread calls `vos_uds_socket_send` to send the registration request data frame to the server's receiving thread through the established Unix domain socket connection; simultaneously, a timeout timer is started, with a preset timeout of 100ms, waiting for the server to return a registration ACK confirmation frame. If no normal ACK response is received after 100ms, and retransmission fails three times, the client connection is closed.

[0110] Step 3: The server processes the registration request. After receiving the data frame sent by the client process, the server's receiving thread first reads the first byte of the frame header to determine the data type: if the first byte is a registration frame identifier (0x04), the data frame is determined to be a registration request; if the first byte is a data frame identifier (0x03), the data frame is determined to be a diagnostic data frame. Once a registration request is determined, the server extracts the Diagnostic Command Identifier (RID) and identity information from the data frame, and retrieves the socket file descriptor (FD) and callback function pointer (handler) from the connection context corresponding to the client process.

[0111] Step 4: The server performs registration verification and storage. The server queries the list of registered client processes based on the process identifier to see if a registration record for the same diagnostic command identifier already exists for the same client process. If it exists, the server returns a registration failure status (0x01) to the client process, rejecting this duplicate registration. If it does not exist, the server further determines whether the diagnostic command identifier is within a preset valid range (e.g., E101 to E199). If it exceeds the preset valid range, the server returns a registration rejection status (0x02) to the client process. If it is within the preset valid range, the server associates and stores the diagnostic command identifier (RID), process identifier (PID), socket file descriptor (FD), and callback function pointer (handler) corresponding to the client process in the local mapping table (the list of registered client processes). The server's receiving thread calls vos_uds_socket_send to return a registration success ACK (0x00) to the client.

[0112] Step 5: The client receives the registration confirmation and completes the registration. If the client receives a registration confirmation frame from the server before the timeout expires, it parses the registration status code: if registration is successful (0x00), the registration process is complete, and the client enters a waiting state for diagnostic instructions; if registration fails (0x01) or registration is rejected (0x02), the registration process is re-initiated. If no registration confirmation frame is received before the timeout expires, the registration request is resent until the maximum number of retries (e.g., 5 times) is reached. If registration is still unsuccessful after reaching the maximum number of retries, the connection between the client process and the server is closed.

[0113] III. Diagnostic Instruction Issuance and Execution Process.

[0114] After receiving the vehicle-side diagnostic instructions from the cloud or host computer, the server enters the diagnostic instruction issuance and execution process.

[0115] Step 1: Parse diagnostic commands and determine destination type. The server parses the received vehicle-side diagnostic commands, extracts the Command Identifier (RID), and determines the destination type. In the attached diagram, destinations are categorized into three types: destination to other Linux processes, destination to the local process, and destination to a remote MCU device. When the destination is a remote MCU device, the server forwards the diagnostic command via a private protocol such as DoIP and waits for the MCU to return the processing result. When the destination is the local process, the server directly executes the processing locally and returns the result. When the destination is another Linux process, the server queries the locally stored mapping table. If no corresponding registration record is found, an error is returned directly. If a record exists, the diagnostic command is distributed to the corresponding target client.

[0116] Step 2: Determine the diagnostic process based on the destination.

[0117] Local execution process: If the destination of the diagnostic command is specified as the current process, the server determines that the diagnostic process is a local execution process, and the server itself directly collects local system information and generates diagnostic response data.

[0118] Remote distribution process: If the destination of the diagnostic command is another Linux process, the remote distribution process is executed, which includes the following sub-steps: Sub-step 2.1: Query the target client process. Based on the command identifier (RID) in the vehicle diagnostic command, the server queries the local mapping table to obtain the socket file descriptor (FD), process identifier (PID), and callback function pointer of the target client process associated with that RID. If no corresponding registration record is found, an error response is returned directly.

[0119] Sub-step 2.2: Determine the dispatch mode. The server determines the diagnostic dispatch mode: asynchronous dispatch mode or synchronous dispatch mode. If the callback function pointer DoipHandler passed in during server initialization is not NULL, the diagnostic dispatch mode is determined to be asynchronous dispatch mode; if DoipHandler is NULL, the diagnostic dispatch mode is determined to be synchronous dispatch mode.

[0120] Sub-step 2.3A: Asynchronous dispatch execution. In asynchronous dispatch mode, the server-side receiving thread calls `vos_uds_socket_send` to send a diagnostic command message to the target client. After sending, it returns immediately without blocking and waiting for a response. The target client-side receiving thread receives the diagnostic message and triggers the call to the handler callback function bound during registration. The target process then performs business diagnostic data collection. After business processing is complete, the client-side receiving thread calls `vos_uds_socket_send` to send a response message carrying the return code and business diagnostic data back to the server-side receiving thread. Upon receiving the response message, the server-side receiving thread triggers the initialization of the passed-in `DoipHandler` callback function and returns a diagnostic command response to the upper layer.

[0121] Sub-step 2.3B: Synchronous Distribution Execution. In synchronous distribution mode, the server-side receiving thread calls `vos_uds_socket_send` to send a diagnostic command message to the target client. After sending, it blocks, initiating a timeout wait to await a response from the client. Upon receiving the diagnostic message, the target client-side receiving thread triggers the call to the handler callback function bound during registration, allowing the target process to collect business diagnostic data. After business processing is complete, the client-side receiving thread calls `vos_uds_socket_send()` to send the diagnostic response message back to the server-side receiving thread. Upon receiving the response message, the server-side receiving thread activates the synchronous waiting logic and outputs the data to the calling interface; if no response is received within the timeout period, it directly returns failure.

[0122] If the destination of the diagnostic command is the MCU remote device, the server forwards the diagnostic command to the MCU remote device through smuggling handling protocols such as DoIP Severdeng, and waits for the MCU to return the processing result; after the MCU completes the processing, it sends the result back to the server receiving thread; if the MCU does not respond, it returns an error response.

[0123] Step 3: Return diagnostic results. The server encapsulates the local execution results, the results returned by the remote client, and the response returned by the MCU remote device in a unified manner, according to a preset format (such as JSON format), and returns it to the caller through the reporting channel specified by the cloud or host computer, completing a complete diagnostic interaction.

[0124] Corresponding to the above method embodiments, this application also provides a vehicle diagnostic device, such as... Figure 6 As shown, the device may include a diagnostic level determination module 601, a diagnostic process determination module 602, and a diagnostic module 603.

[0125] The diagnostic level determination module 601 is used to determine the diagnostic level corresponding to the vehicle-side diagnostic command when a vehicle-side diagnostic command is received. The diagnostic process determination module 602 is used to determine the diagnostic process corresponding to the vehicle-side diagnostic instructions based on the diagnostic level. The diagnostic module 603 is used to diagnose the vehicle according to the diagnostic process corresponding to the vehicle-side diagnostic instructions.

[0126] This application also provides an electronic device, such as... Figure 7 As shown, it includes a processor 701, a communication interface 702, a memory 703, and a communication bus 704, wherein the processor 701, the communication interface 702, and the memory 703 communicate with each other through the communication bus 704. Memory 703 is used to store computer programs; In one embodiment of this application, when the processor 701 executes a program stored in the memory 703, it performs the following steps: Upon receiving a vehicle diagnostic command, determine the diagnostic level corresponding to the command; based on the diagnostic level, determine the diagnostic process corresponding to the command; and perform vehicle diagnostics according to the diagnostic process.

[0127] The communication bus mentioned in the above electronic devices can be a Peripheral Component Interconnect (PCI) bus or an Extended Industry Standard Architecture (EISA) bus, etc. This communication bus can be divided into address bus, data bus, control bus, etc. For ease of illustration, only one thick line is used to represent it in the diagram, but this does not indicate that there is only one bus or one type of bus.

[0128] The communication interface is used for communication between the aforementioned electronic devices and other devices.

[0129] The memory may include random access memory (RAM) or non-volatile memory, such as at least one disk storage device. Optionally, the memory may also be at least one storage device located remotely from the aforementioned processor.

[0130] The processors mentioned above can be general-purpose processors, including central processing units, network processors (NPs), etc.; they can also be digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, or discrete hardware components.

[0131] In another embodiment provided in this application, a storage medium is also provided, which stores instructions that, when run on a computer, cause the computer to execute any of the vehicle diagnostic methods described in the above embodiments.

[0132] In another embodiment provided in this application, a computer program product containing instructions is also provided, which, when run on a computer, causes the computer to perform any of the vehicle diagnostic methods described in the above embodiments.

[0133] In the above embodiments, implementation can be achieved entirely or partially through software, hardware, firmware, or any combination thereof. When implemented using software, it can be implemented entirely or partially in the form of a computer program product. The computer program product includes one or more computer instructions. When the computer program instructions are loaded and executed on a computer, all or part of the processes or functions described in the embodiments of this application are generated. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions can be stored in a storage medium or transmitted from one storage medium to another. For example, the computer instructions can be transmitted from one website, computer, server, or data center to another website, computer, server, or data center via wired (e.g., coaxial cable, fiber optic, digital subscriber line (DSL)) or wireless (e.g., infrared, wireless, microwave, etc.) means. The storage medium can be any available medium that a computer can access or a data storage device such as a server or data center that integrates one or more available media. The available medium can be a magnetic medium (e.g., floppy disk, hard disk, magnetic tape), an optical medium (e.g., DVD), or a semiconductor medium (e.g., solid state disk (SSD)).

[0134] It should be noted that, in this document, relational terms such as "first" and "second" are used merely to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitations, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes said element.

[0135] The various embodiments in this specification are described in a related manner. Similar or identical parts between embodiments can be referred to mutually. Each embodiment focuses on describing the differences from other embodiments. In particular, the system embodiments are basically similar to the method embodiments, so the description is relatively simple; relevant parts can be referred to the descriptions of the method embodiments.

[0136] The above description is merely a specific embodiment of this application, enabling those skilled in the art to understand or implement this application. Various modifications to these embodiments will be readily apparent to those skilled in the art, and the general principles defined herein may be implemented in other embodiments without departing from the spirit or scope of this application. Therefore, this application is not to be limited to the embodiments shown herein, but is to be accorded the widest scope consistent with the principles and novel features claimed herein. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application are included within the protection scope of this application.

Claims

1. A vehicle diagnostic method, characterized in that, Applied to the server side, the method includes: Upon receiving a vehicle-side diagnostic command, determine the diagnostic level corresponding to the vehicle-side diagnostic command; Based on the diagnostic level, the diagnostic process corresponding to the vehicle-side diagnostic command is determined; The vehicle is diagnosed according to the diagnostic process corresponding to the vehicle-side diagnostic command.

2. The method according to claim 1, characterized in that, Determining the diagnostic level corresponding to the vehicle-side diagnostic command includes: The vehicle-side diagnostic command is parsed to obtain command identification information; The diagnostic level corresponding to the vehicle-side diagnostic instruction is determined by querying a preset diagnostic instruction mapping table based on the instruction identifier information.

3. The method according to claim 1, characterized in that, The diagnostic process for determining the vehicle-side diagnostic command based on the diagnostic level includes: If the diagnostic level belongs to the first level or the second level, then the diagnostic process is determined to be a local execution process; If the diagnostic level is the third or fourth level, then the diagnostic process is determined to be a remote distribution process. The first level is used to obtain basic information about the controller hardware and operating system; the second level is used to obtain overall system resource usage information; the third level is used to obtain process-level deep running information; and the fourth level is used to obtain thread-level runtime behavior information.

4. The method according to claim 1, characterized in that, The process of diagnosing the vehicle according to the diagnostic procedure corresponding to the vehicle-side diagnostic command includes: If the diagnostic process is a local execution process, then local system information is collected and diagnostic response data is generated; If the diagnostic process is a remote distribution process, then the registered client process list is queried according to the instruction identifier information in the vehicle-side diagnostic instruction to determine the target client process; the vehicle-side diagnostic instruction is distributed to the target client process, and the diagnostic response data returned by the target client process is received.

5. The method according to claim 4, characterized in that, The list of registered client processes is generated in the following way: Each client process establishes a communication connection with the server through the client initialization interface; When the server receives a registration request sent by any of the client processes through the registration interface, it obtains the diagnostic instruction identifier information, process identifier information and callback processing information corresponding to the client process from the registration request. The diagnostic instruction identifier information, the process identifier information, and the callback processing information corresponding to the client process are associated and stored to generate the registered client process list.

6. The method according to claim 5, characterized in that, After obtaining the diagnostic instruction identifier information, process identifier information, and callback processing information corresponding to the client process from the registration request, the method further includes: Based on the process identification information, query the list of registered client processes to see if there is already a registration record for the same client process with the same diagnostic instruction identification information; If it exists, return a registration failure status to the client process; If it does not exist, then determine whether the diagnostic instruction identification information is within a preset valid range; If it is within the preset valid range, then the step of associating and storing the diagnostic instruction identification information supported by the client process, the process identification information and the callback processing information, generating the registered client process list, and returning the registration success status to the client process; If the value exceeds the preset valid range, a registration rejection status is returned to the client process.

7. The method according to claim 4, characterized in that, The step of distributing the vehicle-side diagnostic command to the target client process and receiving the diagnostic response data returned by the target client process includes: Determine the diagnostic distribution model; When the diagnostic distribution mode is asynchronous distribution mode, the asynchronous distribution interface is called to distribute the vehicle-side diagnostic instructions to the target client process, and the diagnostic response data returned by the target client process is received through callback processing information; When the diagnostic distribution mode is synchronous distribution mode, the synchronous distribution interface is called to distribute the vehicle-side diagnostic instructions to the target client process, and the diagnostic response data is received using the inter-process communication channel.

8. The method according to claim 7, characterized in that, Receiving the diagnostic response data using an inter-process communication channel includes: An inter-process communication channel is created, and the read and write ends of the inter-process communication channel are associated with a global wait structure, which is used to store the diagnostic response data. The inter-process communication channel is monitored via a polling interface. After the target client process completes the diagnostic data collection and writes the diagnostic response data into the global wait structure, it writes notification data through the write end of the inter-process communication channel. When the polling interface detects that there is data to read at the read end of the inter-process communication channel, the diagnostic response data is read from the global wait structure.

9. A vehicle diagnostic device, characterized in that, Applied to the server side, the device includes: The diagnostic level determination module is used to determine the diagnostic level corresponding to the vehicle-side diagnostic command when a vehicle-side diagnostic command is received. The diagnostic process determination module is used to determine the diagnostic process corresponding to the vehicle-side diagnostic instruction based on the diagnostic level. The diagnostic module is used to diagnose the vehicle according to the diagnostic process corresponding to the vehicle-side diagnostic instructions.

10. An electronic device, characterized in that, It includes a processor, a communication interface, a memory, and a communication bus, wherein the processor, the communication interface, and the memory communicate with each other through the communication bus; Memory, used to store computer programs; A processor, when executing a program stored in memory, implements the method described in any one of claims 1-8.

11. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program that, when executed by a processor, implements the method described in any one of claims 1-8.

Images