Diagnostic method, device, medium and automotive diagnostic apparatus for a vehicle

Abstract

This application discloses a vehicle diagnostic method, apparatus, medium, and automotive diagnostic equipment, relating to the field of vehicle diagnostic technology. The method includes: decomposing a user-input diagnostic task into multiple atomic diagnostic tasks, and constructing a task-dependent directed acyclic graph (DAG) based on a preset task dependency rule base to express the logical constraints between tasks. The electronic control unit (ECU) corresponding to each task and its associated physical communication channel are determined. The system dynamically monitors tasks in the ready state in the DAG and sorts them according to preset rules to form a set of ready tasks. Tasks in the set are assigned to task queues of their respective channels, and the system ultimately controls the concurrent execution of tasks in different channel queues and the sequential execution of tasks in the same channel queue. This application ensures the logical correctness of the diagnostic process, fully utilizes the parallel communication capabilities of multiple vehicle channels, and significantly improves diagnostic efficiency and system reliability.

Description

Technical Field

[0001] This application relates to the field of vehicle diagnostic technology, and more particularly to a vehicle diagnostic method, apparatus, medium, and automotive diagnostic equipment. Background Technology

[0002] Vehicles typically have multiple ECUs (Electronic Control Units) distributed across different buses, such as CAN (Controller Area Network), CAN FD (CAN with Flexible Data-Rate), LIN (Local Interconnect Network), and Ethernet. When automotive diagnostic equipment initiates a diagnostic task, it may need to access multiple ECUs. Existing diagnostic solutions often employ serial execution or simple task queuing, resulting in lengthy overall diagnostic times. Therefore, improving the efficiency of diagnostic tasks and reducing execution time is a pressing issue. Summary of the Invention

[0003] This application provides a vehicle diagnostic method, apparatus, medium, and automotive diagnostic equipment, which can solve the technical problem of low execution efficiency in existing diagnostic operations. The technical solution is as follows: In a first aspect, embodiments of this application provide a vehicle diagnostic method, the method comprising: Decompose the diagnostic job input by the user into multiple atomic diagnostic tasks; Based on a preset task dependency rule base, a Directed Acyclic Graph (DAG) is constructed for the multiple atomic diagnostic tasks; wherein, the nodes in the DAG represent atomic diagnostic tasks, and the directed edges represent the execution dependencies between atomic diagnostic tasks. Identify the ECU corresponding to each of the multiple atomic diagnostic tasks, and determine the communication channel of each ECU; The DAG monitors at least one ready task in a ready state, and generates a ready task set by sorting the at least one ready task according to a preset sorting rule. Each ready task in the ready task set is assigned to the task queue of its respective communication channel for execution; It concurrently executes ready tasks in the task queues corresponding to different communication channels, and sequentially executes ready tasks in the task queues corresponding to the same communication channel.

[0004] Secondly, embodiments of this application provide a diagnostic device for a vehicle, the device comprising: The decomposition module is used to break down the diagnostic job input by the user into multiple atomic diagnostic tasks; The construction module is used to construct a Directed Acyclic Graph (DAG) for the multiple atomic diagnostic tasks according to a preset task dependency rule library; wherein, the nodes in the DAG represent atomic diagnostic tasks, and the directed edges represent the execution dependencies between atomic diagnostic tasks. The determination module is used to determine the ECU corresponding to each of the multiple atomic diagnostic tasks, and to determine the communication channel where each ECU is located; The generation module is used to generate a set of ready tasks by sorting the at least one ready task in the ready state of the DAG monitoring according to a preset sorting rule. The allocation module is used to allocate each ready task in the ready task set to the task queue of its respective communication channel for execution; The execution module is used to concurrently execute ready tasks in the task queues corresponding to different communication channels, and to sequentially execute ready tasks in the task queues corresponding to the same communication channel.

[0005] Thirdly, embodiments of this application provide a computer storage medium storing a plurality of instructions adapted for loading by a processor and executing the above-described method steps.

[0006] Fourthly, embodiments of this application provide an automotive diagnostic device, which may include: a processor and a memory; wherein the memory stores a computer program adapted to be loaded by the processor and to execute the above-described method steps.

[0007] The beneficial effects of the technical solutions provided in some embodiments of this application include at least the following: This application decomposes user diagnostic tasks and constructs them into a task-dependent directed acyclic graph, enabling the formal modeling and strict adherence to the complex temporal, data, and security dependencies between atomic diagnostic tasks. This mechanism enforces the logical correctness of the diagnostic process at the system level, preventing operational inconsistencies, data discrepancies, or process interruptions caused by incorrect task execution order.

[0008] This application achieves intelligent scheduling of multi-channel communication resources in vehicles by mapping tasks to specific communication channels and dynamically sorting and allocating ready tasks based on the real-time status of the channels. This allows tasks that might otherwise be blocked due to serial execution to be rationally allocated to different physical channels for parallel execution based on dependency constraints and channel availability. This significantly improves the utilization rate of communication bandwidth and the concurrency of task execution, thereby greatly reducing the overall time consumption of complex diagnostic operations and improving diagnostic efficiency. Attached Figure Description

[0009] 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, the drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0010] Figure 1 This is a schematic diagram of the system architecture provided in the embodiments of this application; Figure 2 This is a schematic flowchart of a vehicle diagnostic method provided in an embodiment of this application; Figure 3 This is a schematic diagram of the construction process of a directed acyclic graph provided in an embodiment of this application; Figure 4 This is a schematic diagram of the structure of a vehicle diagnostic device provided in this application; Figure 5 This is a schematic diagram of a computer storage medium provided in this application; Figure 6 This is a structural schematic diagram of an automotive diagnostic device provided in this application. Detailed Implementation

[0011] To make the objectives, technical solutions, and advantages of this application clearer, the embodiments of this application will be described in further detail below with reference to the accompanying drawings.

[0012] It should be noted that the vehicle diagnostic methods provided in this application are generally performed by automotive diagnostic equipment, and correspondingly, the vehicle diagnostic device is generally located in the automotive diagnostic equipment.

[0013] Figure 1 An exemplary system architecture is shown that can be applied to the diagnostic methods for vehicles or the processing apparatus for vehicle diagnostic data of this application.

[0014] like Figure 1 As shown, the system architecture may include: a target vehicle 100, an automotive diagnostic device 101, and a cloud-based diagnostic management platform 102. The automotive diagnostic device 101 and the cloud-based diagnostic management platform 102 can communicate via a network, which serves as the medium for providing communication links between the various units. The network may include various types of wired or wireless communication links, such as: wired communication links including fiber optic cables, twisted-pair cables, or coaxial cables; and wireless communication links including Bluetooth, Wi-Fi, or microwave communication links. The target vehicle 100 and the automotive diagnostic device 101 communicate via an automotive diagnostic interface.

[0015] In this process, the user initiates a diagnostic job through the human-machine interface of the vehicle diagnostic device 101. After receiving the job instruction, the vehicle diagnostic device 101 first parses it locally, decomposes it into multiple atomic diagnostic tasks, and constructs an initial task dependency directed acyclic graph based on its locally stored task dependency rule base.

[0016] If the diagnostic task involves complex logical arrangements or the target vehicle 100 is a new model, the automotive diagnostic device 101 can initiate a query request to the cloud-based diagnostic management platform 102. This request typically includes the vehicle identification number (VIN) of the target vehicle 100 and the characteristic identifier of the diagnostic task. The cloud-based diagnostic management platform 102 processes the request based on its maintained full-scale vehicle model database, global task dependency rule base, and diagnostic strategy model, and sends relevant rule supplements, atomic task template updates, or scheduling optimization parameters to the automotive diagnostic device 101. Based on this, the automotive diagnostic device 101 refines or corrects its local directed acyclic graph of task dependencies and task attribute parameters.

[0017] During the task scheduling and execution phase, the automotive diagnostic device 101 interacts directly with the target vehicle 100. Based on the constructed directed acyclic graph of task dependencies and combined with the real-time status information of each communication channel obtained from the target vehicle 100's network, the automotive diagnostic device 101 dynamically schedules ready atomic diagnostic tasks. The automotive diagnostic device 101 sends diagnostic request messages conforming to the protocol format to specific electronic control units within the target vehicle 100 through its connected physical communication channels and receives response messages from the target vehicle 100. This process strictly adheres to dependencies and scheduling order, achieving concurrent execution across channels and sequential execution within channels.

[0018] During task execution, the automotive diagnostic device 101 continuously monitors the execution status. If it encounters anomalies that cannot be handled by the local rule base, or if it needs to obtain the latest software update packages or other resources, the automotive diagnostic device 101 will upload the anomaly context information or resource request to the cloud-based diagnostic management platform 102. The cloud-based diagnostic management platform 102 can perform intelligent analysis and provide solutions or distribute the necessary resource files to the automotive diagnostic device 101.

[0019] After the diagnostic work is completed, the vehicle diagnostic device 101 generates a detailed execution report. This report can be saved locally or selectively uploaded by the vehicle diagnostic device 101 to the cloud-based diagnostic management platform 102 to enrich the platform's diagnostic case library and support the cloud-based diagnostic management platform 102 in continuously optimizing the global vehicle rule base and estimated execution time model based on data.

[0020] It should be noted that the cloud-based diagnostic management platform 102 includes one or more servers. If there are multiple servers, it can be implemented as a distributed server cluster composed of multiple servers, which is not specifically limited here.

[0021] The automotive diagnostic device 101 can be a variety of portable diagnostic devices with a display screen, including but not limited to smartphones, tablets, laptops, and desktop computers.

[0022] It should be understood that Figure 1 The number of portable diagnostic devices, networks, and servers shown is merely illustrative. Any number of portable diagnostic devices, networks, and servers can be used depending on implementation needs.

[0023] It should be understood that Figure 1 The number of automotive diagnostic devices, networks, and servers shown is merely illustrative. Any number of such devices, networks, and servers can be used depending on implementation needs.

[0024] The following will be combined with the appendix Figure 2 This application provides a detailed description of the vehicle diagnostic method provided in its embodiments. The vehicle diagnostic device in these embodiments may be... Figure 1 The vehicle diagnostic equipment shown.

[0025] Please see Figure 2 This is a flowchart illustrating a vehicle diagnostic method provided in this application. Figure 2 As shown, the method described in this application embodiment may include the following steps: S1. Decompose the diagnostic job input by the user into multiple atomic diagnostic tasks.

[0026] A diagnostic task refers to an operation command initiated by a user through the human-machine interface of an automotive diagnostic device or input through an external command interface. A diagnostic task may include: a task identifier, a task type code, a target object list, and a task description. The task identifier uniquely identifies the diagnostic task; the task type code indicates the type of diagnostic task; the target object list identifies one or more ECUs; and the task description describes the task content and operational intent. An atomic diagnostic task represents the smallest indivisible executable unit that conforms to a specific vehicle diagnostic communication protocol standard format.

[0027] Automotive diagnostic equipment can decompose diagnostic jobs into multiple atomic diagnostic tasks based on a pre-defined atomic task template library. This library is built upon the diagnostic communication protocol standards used by the target vehicle network, such as the Unified Diagnostic Service Protocol (UDS). The atomic task template library includes fields such as: Service Identifier (SID), basic request message format, parameter template, and response processing logic template. For each basic diagnostic service supported by the protocol, the library defines a corresponding template entry; each template entry specifies the unique service identifier corresponding to the diagnostic job at the protocol layer, the basic format framework of the standard request message, and the necessary parameter field definitions and constraints. When the diagnostic equipment decomposes a user-input diagnostic job, it matches the operational intent in the job description with entries in the library, instantiating each operational intent into an atomic diagnostic task conforming to the protocol specification. Each atomic diagnostic task may include: a protocol service identifier, the address of the target electronic control unit, a parameter list, and relevant context information.

[0028] Furthermore, the atomic task template library is related to the Unified Diagnostic Service Protocol (UDP), which represents a standardized language for diagnostic communication between vehicle electronic control units and diagnostic equipment, defining service identifiers, request and response message formats, parameter meanings, and session states.

[0029] For example, suppose a user submits a diagnostic job to a vehicle diagnostic device with the description "Read and clear engine control unit fault codes". The diagnostic device parses the job description and identifies two core operations: "Read fault codes" and "Clear fault codes", both targeting the "engine control unit". It then queries the atomic task template library. Assume the library contains pre-stored "Read Fault Code Service" and "Clear Fault Code Service" templates based on the Unified Diagnostic Service Protocol, each associated with a unique service identifier and message format definition. Based on the first operation, an atomic diagnostic task is created. This task's service identifier is set to the standard value corresponding to "Read Fault Codes", its target ECU identifier is set to the logical address of the engine control unit, and the parameter is specified as requesting all fault codes. Based on the second operation, another atomic diagnostic task is created. This task's service identifier is set to the standard value corresponding to "Clear Fault Codes", its target ECU identifier also points to the logical address of the engine control unit, and the parameter is specified as clearing all fault codes. Thus, the user-input diagnostic job is decomposed into two independent atomic diagnostic tasks.

[0030] S2. Construct a DAG for multiple atomic diagnostic tasks based on a preset task dependency rule base.

[0031] The DAG (Directed Acyclic Graph) is built upon a pre-defined task dependency rule base. This rule base is a structured dataset where each dependency rule defines the execution order that must be followed between two types of atomic diagnostic tasks under specific conditions. This order can be temporal, data input / output, or mutually exclusive resource access. Nodes in the DAG represent atomic diagnostic tasks, and directed edges represent the execution dependencies between these tasks.

[0032] The construction process of a Directed Acyclic Graph (DAG) includes: initializing an empty task-dependent DAG data structure; creating each atomic diagnostic task as an independent node in the graph, recording the core attributes of the task within the node; performing dependency analysis to examine the relationship between every two atomic diagnostic task nodes, using the specific task types, target electronic control unit identifiers, and relevant parameters as query conditions to retrieve the task dependency rule base; if a matching dependency rule is found, adding a directed edge between the corresponding two nodes according to the dependency direction indicated by the rule; the directed edge points from the predecessor task node to the successor task node that depends on it, thus visually encoding the execution constraints between tasks in the graph; and finally, performing a loop detection analysis to ensure that there are no cyclic dependency paths in the DAG, thus guaranteeing that the final DAG is logically executable.

[0033] For example, suppose the diagnostic device receives three atomic diagnostic tasks from step S1: Task A: read engine control unit fault codes, Task B: clear engine control unit fault codes, and Task C: read wheel speed data from the anti-lock braking system control unit. The process of constructing a DAG includes: First, create an empty graph, and then initialize task A, task B, and task C as three independent nodes.

[0034] Next, the dependency analysis begins. First, tasks A and B are analyzed. Based on their task types and target ECU identifiers, the engine queries the task dependency rule base. A rule exists in the rule base that states, "If two atomic diagnostic tasks have the same target ECU identifier, and their task types are 'read fault codes' and 'clear fault codes' respectively, then the 'clear fault codes' task depends on the 'read fault codes' task." This rule is successfully matched. Therefore, a directed edge is added to the graph from the task A node to the task B node.

[0035] Next, we analyze tasks A and C, as well as tasks B and C. Because they are different task types and have different target ECU identifiers, no applicable dependency rules were found in the task dependency rule base. Therefore, no directed edges are established between these nodes.

[0036] Ultimately, a directed acyclic graph containing three nodes and one directed edge is generated, indicating that task B must be executed after task A, while there is no direct order constraint between task C and tasks A and B.

[0037] S3. Determine the ECU corresponding to each of the multiple atomic diagnostic tasks, and determine the communication channel of each ECU.

[0038] The automotive diagnostic equipment determines the ECU associated with each atomic diagnostic task based on the preset mapping relationship between ECUs and atomic diagnostic tasks. For example, the automotive diagnostic equipment parses the ECU identifier associated with the atomic diagnostic task. The ECU identifier is a digital code that conforms to the vehicle network addressing specification and is used to uniquely represent the specific ECU that the atomic diagnostic task intends to access.

[0039] Automotive diagnostic equipment relies on a maintained network topology table. This table is a data structure that records the identifiers and attributes of each communication channel in the current vehicle network, as well as the identifiers of one or more communication channels connected to each known electronic control unit (ECU). The equipment uses the ECU identifier obtained in the first phase as a lookup key to search and match within the network topology table. The communication channel identifier associated with that address in the table entry represents the physical form of the communication channel used for that atomic diagnostic task.

[0040] For example, suppose the diagnostic equipment processes three atomic diagnostic tasks. Task 1's ECU identifier is 0x7E0, Task 2's is 0x750, and Task 3's is 0x700. Reading these three ECU identifiers, we determine that Task 1's ECU is the engine control unit, Task 2's is the lighting control module, and Task 3's is the central gateway module. Then, we query the network topology table, which records that ECU identifier 0x7E0 corresponds to channel CAN1, ECU identifier 0x750 corresponds to channel LIN1, and ECU identifier 0x700 corresponds to channel CAN2. After mapping, Task 1 is assigned to channel CAN1, Task 2 to channel LIN1, and Task 3 to channel CAN2.

[0041] S4. Monitor at least one ready task in the DAG state and generate a ready task set by sorting at least one ready task according to a preset sorting rule.

[0042] The automotive diagnostic equipment dynamically determines at least one ready task in the ready state based on the current state of the directed acyclic graph. The ready state represents a task that can be scheduled for execution. Then, the at least one ready task is sorted to form a ready task set.

[0043] The specific process includes: traversing the execution state of each node in the directed acyclic graph (DAG) for each atomic diagnostic task. Traversing all nodes in the DAG, a conditional judgment is performed on each node marked as waiting to be executed. The condition for judgment is to check whether all direct predecessor nodes of the node are in a successful execution state. If all direct predecessor nodes of a node are in a successful state, then the node meets the logical prerequisite for execution and is identified as a ready task at the current moment. The device collects all nodes that meet this condition to form an initial ready task list.

[0044] The diagnostic equipment sorts the initial list of ready tasks according to a preset sorting rule. This sorting rule evaluates task priority across multiple dimensions. Key dimensions include task attributes such as whether they are marked as safety-critical, and the real-time resource status of the target communication channel, such as its current load rate or queue length. A comprehensive priority score is calculated for each ready task in the list based on these dimensions, and the tasks are then rearranged according to their priority scores. This ordered list constitutes the set of ready tasks for the current scheduling cycle.

[0045] In actual scheduling, a weighted scoring method can be used to integrate multiple ranking dimensions. For example: Priority Score = W1 × Security Level Coefficient + W2 × (1 - Channel Load Rate) + W3 × (1 / Estimated Execution Time), and sorted in descending order of score. The Security Level Coefficient is a predefined numerical level identifier based on the operational nature of the atomic diagnostic task, used to characterize the degree of impact of the task on vehicle functional safety or system safety. For example, tasks involving secure access authentication, critical control unit programming, or high-privilege function operations are assigned higher coefficient values, while routine monitoring tasks that only read data are assigned lower coefficient values. The Channel Load Rate is a quantitative indicator of the resource occupancy status of the target physical communication channel at the current moment, with a value ranging from 0 to 1. It can be obtained by real-time monitoring of the length of the pending task queue on the channel, the ratio of message traffic per unit time to its maximum theoretical bandwidth, or a combination of both. The Estimated Execution Time is a typical execution time prediction value determined for various atomic diagnostic tasks based on historical execution logs through statistical analysis (such as calculating the average or median), and its unit is usually milliseconds. The weights W1, W2, and W3 are preset configurable parameters between 1 and 0. Their specific values ​​are determined by system developers or users based on the relative importance placed on the three optimization objectives of security, load balancing, and execution efficiency in the actual diagnostic scenario. For example, W1 can be increased in scenarios emphasizing job reliability, while W3 can be increased in scenarios requiring maximum throughput. This weighted calculation model allows for dynamic quantitative evaluation and prioritization of ready tasks, thereby achieving comprehensive optimized scheduling that prioritizes security, balances resource load, and optimizes overall execution efficiency.

[0046] For example, suppose there are five nodes in the directed acyclic graph maintained by the diagnostic equipment, representing tasks A to E respectively, and their current states are: A (success), B (success), C (in execution), D (waiting), and E (waiting). The known dependencies are: C depends on A, D depends on B, and E depends on C.

[0047] In the state identification phase, all nodes are traversed. For task D in the waiting state, its direct predecessor is B, and B's state is successful; therefore, D is identified as a ready task. For task E in the waiting state, its direct predecessor is C, and C's state is executing, not successful; therefore, E is not identified as ready. Tasks A, B, and C, because their states are not waiting, do not participate in this readyness determination. Ultimately, the initial ready task list only contains task D.

[0048] Suppose that in the next moment, task C completes its execution and changes its status to successful. The scheduling module performs another check. At this time, the direct predecessor of task E, C, is already in a successful state, so task E is also identified as ready. The initial list of ready tasks is updated to include tasks D and E.

[0049] During the task sorting process, the device queries the preset sorting rules. Assume task D is marked as a safety-critical task with a target communication channel load of 40%; task E is a non-safety-critical task with a target communication channel load of 80%. Based on the rules of prioritizing safety-critical tasks and prioritizing tasks with lower load, task D is calculated to have a higher priority than task E. Therefore, the device sorts the list to generate a final ordered set of ready tasks, in the order [D, E].

[0050] S5. Assign each ready task in the ready task set to the task queue of its respective communication channel for execution.

[0051] The automotive diagnostic equipment processes each ready task in the ready task set sequentially. For the currently processed ready task, the target communication channel for the task is first determined based on the task-channel mapping relationship established in step S3. Then, a first-in-first-out (FIFO) task queue corresponding to the target communication channel is accessed. The task queue is a buffer located in the device's memory, used to cache all diagnostic tasks waiting to be sent through this physical channel. The description information of the currently ready task is added as a new entry to the end of the task queue. This process is repeated until all tasks in the ready task set have been placed into the task queue of their respective target channels.

[0052] Once a ready task is successfully added to the task queue, the corresponding task queue's status flag is updated. The status flag indicates whether there are any new tasks awaiting processing in the task queue. The system continuously polls or monitors the corresponding queue status flag via an interrupt mechanism. Once the queue status is detected to be non-empty, it confirms that a task is waiting to be executed, and the task acquisition and message sending process is initiated.

[0053] For example, suppose the current set of ready tasks includes Task A (reading engine speed) and Task B (querying window status), where Task A has higher priority. Task A is processed first. A lookup of the mapping relationship reveals that Task A's target channel is CAN_Engine. The task queue for the CAN_Engine channel is then located, and Task A's description information is added to the end of that queue. Task B is then processed. A lookup reveals that its target channel is LIN_Door. The task queue dedicated to the LIN_Door channel is located, and Task B's description information is added to the end of that queue.

[0054] At this point, the CAN_Engine channel's task queue contains task A, and the LIN_Door channel's task queue contains task B. The task queue status flags for both channels are updated to "not empty." The controllers of the CAN_Engine channel and the LIN_Door channel independently detect the change in their respective queue statuses and begin executing the tasks in their respective queues. Through this allocation mechanism, tasks are effectively distributed to different physical resource paths.

[0055] S6. Execute ready tasks in the task queues corresponding to different communication channels concurrently, and execute ready tasks in the task queues corresponding to the same communication channel sequentially.

[0056] The communication channel is associated with a task queue. The automotive diagnostic equipment monitors this queue, and when it is not empty, a sequential processing flow is initiated: the first atomic diagnostic task is retrieved from the head of the queue. Based on the protocol service identifier, target ECU identifier, and parameters defined for that task, a standard format diagnostic request message is assembled and sent to the vehicle network via its physical channel. After sending, it waits to receive a response message from the target electronic control unit. The response message is parsed according to the diagnostic communication protocol specification, for example, by identifying positive or negative response codes in the message, to determine whether the final execution status of the atomic diagnostic task is success or failure. Only after the current task has been processed and its execution status has been obtained will the next task be retrieved from the queue and the same process executed, thus ensuring that all tasks on the same communication channel are executed sequentially.

[0057] The task queues on different communication channels operate independently. Therefore, while processing tasks in the first channel queue, tasks in the second channel queue can be processed simultaneously, thereby enabling concurrent execution of tasks on different physical communication channels and improving task processing efficiency.

[0058] For example, suppose a car diagnostic device has two communication channel controllers operating. The CAN channel controller manages the CAN bus task queue, currently containing task A (reading data) and task B (writing configuration). The LIN channel controller manages the LIN bus task queue, currently containing task C (reading switch status). The CAN channel controller retrieves task A, sends a read request, and upon receiving a message containing a positive response code, determines that task A has succeeded before retrieving and processing task B. While the CAN channel controller processes task A, the LIN channel controller independently retrieves task C, sends a request, and processes the response. Therefore, tasks A and C execute concurrently. Task B can only begin after task A has completed. Once the status of tasks A and C (e.g., successful) is updated in the task dependency directed acyclic graph, subsequent tasks that depend on them in the graph meet the readiness conditions and are thus included in the next round of scheduling.

[0059] In one possible embodiment, see Figure 3 , Figure 3 This is a schematic diagram of the construction process of a directed acyclic graph provided in an embodiment of this application, including the following steps: S21. Based on the time-series dependency rules, data dependency rules, and security mutual exclusion dependency rules in the preset task dependency rule base, determine the sequential relationship between any two atomic diagnostic tasks in multiple atomic diagnostic tasks.

[0060] Specifically, based on a pre-defined task dependency rule base, the sequential relationships between multiple atomic diagnostic tasks are determined. The task dependency rule base is a data set representing multiple dependency rules, which are mainly divided into three categories: temporal dependency rules, indicating a fixed sequence between two types of tasks defined based on the diagnostic business process; data dependency rules, indicating that the output data generated by one atomic diagnostic task is a necessary input for the execution of another atomic diagnostic task; this rule typically establishes the relationship between tasks by associating specific data identifiers; and security mutual exclusion dependency rules, indicating that two or more tasks cannot execute simultaneously because they need to access the same protected resource; one task must start only after the other task has completed its access to the resource.

[0061] For example, suppose there are two atomic diagnostic tasks to be analyzed. Task 1 requests to download new software data to the transmission control unit (ECU), and Task 2 transfers a data block to the ECU. Task 1 is identified as "Request Download," with the target ECU identified as the ECU address, and its parameters include a memory address range. Task 2 is identified as "Transfer Data," with the same target ECU identifier. A query of the task dependency rule base reveals a data dependency rule that, for the same target ECU identifier, the logical memory block operated on by the "Transfer Data" task must be within the memory address range successfully allocated and initialized by the "Request Download" task. The engine matches this rule, thus determining that there is a sequential relationship between Task 1 and Task 2, with Task 1 being the predecessor of Task 2, and Task 2 depending on the memory allocation result completed by Task 1. For example, in the UDS service, the "$2E WriteDataByIdentifier" task may depend on the successful execution of the "$27 SecurityAccess" task, which falls under a security mutual exclusion dependency rule.

[0062] S22. Construct a DAG for multiple atomic diagnostic tasks based on their sequential relationship.

[0063] After obtaining the sequence relationships between all tasks, the automotive diagnostic equipment constructs a Directed Acyclic Graph (DAG) representing the task dependencies. First, a new graph object is initialized in system memory, containing an empty set of nodes and an empty set of edges. Then, each atomic diagnostic task is created as an independent node in the graph and added to the node set. Next, the relationship list generated in step S21 is traversed. For each sequence relationship in the list, the corresponding predecessor and successor task nodes are found in the graph structure. Then, a directed edge is created between these two nodes, pointing from the predecessor node to the successor node, and this edge is added to the graph's edge set.

[0064] In one possible embodiment, monitoring at least one ready task in a ready state during DAG monitoring includes: A1. Traverse the state of each node in the DAG; A2. For each node, check whether its own status is "not executed" and check whether the status of all its direct predecessor nodes is "successful". A3. If yes, then the atomic diagnostic task associated with this node is designated as a ready task.

[0065] In step A1, to identify the atomic diagnostic tasks that can be scheduled for execution, a systematic state retrieval of the directed acyclic graph (DAG) that the tasks depend on is initiated. Each node in the graph is visited sequentially. When visiting each node, the state attribute value stored in that node's data structure is read. This state value is dynamically updated as the task is executed, representing the task's stage (waiting, executing, successful, or failed). The purpose of this traversal is to obtain the latest, unified state view of all nodes in the graph, providing a complete data foundation for subsequent readiness logic judgments.

[0066] Assume the task depends on a directed acyclic graph containing five nodes. Nodes one through five are visited sequentially, and their state attributes are read. The results are: node one is in "Executing", node two is in "Success", node three is in "Waiting", node four is in "Waiting", and node five is in "Failure". At this point, the module has completed the collection of the current states of all nodes in the graph.

[0067] In step A2, after obtaining the status of each node, a strict double-condition check is performed on each node with a status value of "waiting" to determine whether it has met all logical prerequisites. The first check confirms that the node's own status attribute value is indeed "waiting." The second check confirms that the status attribute values ​​of all of the node's direct predecessor nodes are "successful." Direct predecessor nodes are determined based on the topological connections of the task-dependent directed acyclic graph, i.e., all nodes that directly point to the current node through directed edges. The scheduling module needs to locate these predecessor nodes based on the graph's connection information and compare their status values ​​one by one. Only when both of these checks are true is the node determined to have met all the logical conditions for transitioning to the executable state.

[0068] Continuing the previous example, we will check nodes three and four, which are in the "waiting" state. For node three, its own state satisfies the first check. Based on the graph topology, we find node three's two direct predecessors: node one and node two. The check reveals that node one's state is "in execution," not "successful," therefore the second check fails. For node four, its own state satisfies the first check. Assuming node four has only one direct predecessor, node two, and node two's state is "successful," therefore node four's second check succeeds.

[0069] In step A3, a node is considered ready if and only if all dual-condition checks for that node pass. Subsequently, an output operation is performed: the atomic diagnostic task instance corresponding to that node is added to a separate data container used to cache tasks awaiting scheduling; this container is the ready task set. This set, as the output of this step, contains all tasks that are logically ready in the current graph state and can be further processed by the scheduler. By periodically or event-drivenly repeating this process, the ready task set can be dynamically maintained, responding in real-time to state changes in the task-dependent directed acyclic graph caused by task completion.

[0070] For example, in the above verification, only node four passed all the conditions. Therefore, the scheduling module adds the atomic diagnostic task corresponding to node four, such as a task to "read the vehicle control module data stream," to the ready task set. Node three, because its conditions were not met, will not have its corresponding task added to the ready task set for the current cycle.

[0071] The automotive diagnostic equipment of this application can automatically, accurately, and reliably filter out all atomic diagnostic tasks whose pre-conditions have been satisfied based on the real-time topology and state of the task-dependent directed acyclic graph. It transforms complex task dependencies into programmable state logic judgments, ensuring that only currently executable tasks are submitted to subsequent scheduling stages. This provides key and accurate input for the system to achieve efficient, orderly, and conflict-free concurrent scheduling, thereby improving the automation and execution efficiency of the diagnostic process.

[0072] In one possible embodiment, at least one ready task is sorted according to a preset sorting rule to generate a ready task set, including: B1. Prioritize atomic diagnostic tasks with higher security levels; or, B2. Prioritize atomic diagnostic tasks with low real-time load on the corresponding communication channel; or, B3. Prioritize atomic diagnostic tasks with shorter estimated execution times.

[0073] In this system, automotive diagnostic equipment sorts identified ready atomic diagnostic tasks according to its configured sorting rules to determine their execution order. The sorting rules can be implemented by calculating and comparing task priority scores based on task attributes and real-time system status. Several typical sorting rule implementation methods are described below.

[0074] In step B1, when making prioritization decisions, the automotive diagnostic equipment considers the security level of atomic diagnostic tasks as a factor; a higher security level indicates a higher security requirement for the atomic diagnostic task. Internally, each atomic diagnostic task object contains an attribute field that identifies its security level. This identifier is assigned based on predefined classification rules. For example, operations involving secure access authentication, software rewriting, or resetting critical control unit functions are classified and marked as high-security tasks. When sorting the set of ready tasks, the scheduling module reads this identifier field from each task in the set. According to a preset sorting strategy, the module prioritizes tasks marked as high-security tasks over unmarked or low-security tasks. This mechanism ensures that operations with a significant impact on system security or vehicle functional integrity receive priority scheduling.

[0075] For example, suppose the ready task set includes task A (reading the vehicle interior temperature), task B (secure access to the brake control unit), and task C (setting the entertainment system volume). Based on a predefined classification, task B is marked as high security, while tasks A and C are not marked. According to this rule, the scheduling module will prioritize task B in the set. The relative order of tasks A and C is determined by other rules.

[0076] In B2, the automotive diagnostic equipment considers the real-time resource occupancy of the target communication channels when making sequencing decisions. The diagnostic equipment includes a channel status monitoring unit that periodically or based on events collects performance data for each physical communication channel and calculates a real-time load metric. This metric can be the channel packet traffic occupancy rate, the instantaneous length of the pending packet queue, or a combined function of both. When sequencing the set of ready tasks, the scheduling module queries the channel status monitoring unit for the current real-time load metric of the target channel corresponding to each task in the set. Based on a preset sequencing strategy, tasks with lower real-time load metrics for the target channel are prioritized over tasks with higher load metrics. This strategy aims to dynamically direct tasks to relatively idle channels to achieve load balancing, avoid overloading a single channel, thereby optimizing overall communication efficiency and reducing task queuing latency.

[0077] For example, suppose the ready task set includes task X (target channel CAN1) and task Y (target channel CAN2). The channel status monitoring unit currently reports a load metric of 85 for CAN1 and a load metric of 30 for CAN2. According to this rule, the scheduling module will prioritize task Y (corresponding to the low-load channel CAN2) before task X (corresponding to the high-load channel CAN1).

[0078] In step B3, the automotive diagnostic equipment refers to the estimated execution time of atomic diagnostic tasks when making sorting decisions. A data source is maintained to provide baseline time estimates for various atomic diagnostic tasks. This data source can be a static configuration table based on the service timeout time defined in the diagnostic protocol specification; or it can be a dynamic learning model that continuously updates the time estimate by recording historical execution records and performing statistical analysis. When sorting the set of ready tasks, this data source is queried to obtain the estimated execution time for each task in the set. According to a preset sorting strategy, tasks with shorter estimated execution times are placed before those with longer estimated execution times. This strategy helps to quickly complete lightweight tasks, promptly releasing the system and channel resources they occupy, thereby improving the overall system throughput and responsiveness. The initial value of the estimated execution time can be set based on the service timeout time specified in the diagnostic communication protocol, or obtained through pre-testing.

[0079] For example, suppose the ready task set contains task P (estimated execution time 80 milliseconds), task Q (estimated execution time 200 milliseconds), and task R (estimated execution time 1500 milliseconds). According to this rule, the scheduling module will sort task P first, followed by task Q, and finally task R.

[0080] In one possible embodiment, the method of this application further includes: C1. When an atomic diagnostic task fails, determine all subsequent tasks of that atomic diagnostic task based on the DAG.

[0081] When the automotive diagnostic equipment determines that an atomic diagnostic task has failed, it generates a failure event containing the task identifier. In response to this event, the engine accesses the directed acyclic graph (DAG) of task dependencies maintained in system memory to locate the node corresponding to the failed task. Starting from this node, the engine executes a graph traversal algorithm. This algorithm searches along all directed edges originating from this node, recursively visiting every direct or indirect successor node. The traversal continues until no new successor node can be visited. The engine records all nodes visited during this process, and the atomic diagnostic tasks associated with these nodes—that is, all the successor tasks defined as the failed task.

[0082] For example, suppose the task "Perform secure access to the gateway module" fails, and the corresponding node in the diagram is G1. The exception handling engine starts traversing from node G1. It finds that node G2 (configures the gateway routing table) is the direct successor of G1. Continuing the traversal, it finds that node G3 (verifies the configuration result) is also a direct successor of G2. Therefore, the engine determines that the tasks associated with nodes G2 and G3 are the successors of the failed task G1. Other task nodes in the diagram that are not path-connected to G1 are not included.

[0083] C2. Set all subsequent tasks to a blocked state.

[0084] In this process, based on the traversal results of step C1, a state update is performed on all identified successor tasks. The engine visits the corresponding nodes of these successor tasks in the graph one by one and modifies their internal state attribute values ​​to a specific enumeration value or flag indicating "blocked". This state update is performed on the task-dependent directed acyclic graph data structure. After modification, the state attribute of these nodes in the graph is permanently (or remains "blocked" until a specific cleanup condition is met). When the ready task judgment process is executed subsequently, nodes with the state attribute of "blocked" will be directly excluded regardless of the state of their predecessor nodes, and will not be considered for addition to the ready task set.

[0085] For example, continuing from the previous example, the exception handling engine sets the state attribute of nodes G2 and G3 to "blocked". Subsequently, when the scheduler performs the next round of scheduling scans and reads that G2 and G3 are "blocked", it will ignore them, even if the state of their predecessor task (e.g., G1) changes in the future. This causes the entire configuration process branch that relies on failure-safe access to be automatically suspended by the system.

[0086] C3. Retry the atomic diagnostic task according to the preset strategy, or skip the atomic diagnostic task.

[0087] After controlling the propagation of fault effects, the failed original task is handled. A pre-configured exception handling strategy library is queried. This library is a collection of rules, each associated with a task type, failure reason code, and specific handling instructions. The engine takes the task type identifier and failure reason code of the currently failed task as input and performs a match search in the strategy library.

[0088] Based on the matched policy rules, corresponding actions are executed. Typical actions include two types. First, a retry operation: the failed task's status is reset to "waiting," a retry counter and a delay timer are started, and the task is resubmitted to the scheduling queue after the timer expires. This process is repeated until success or the maximum number of retries is reached. Second, a skip operation: the final status of the failed task is marked as "skipped" or "failed," and a log record or user notification is generated. The rules in the policy library can be finely defined. For example, for "secure access" tasks that fail due to "key error," the rule can directly specify "skip" and no retry; for tasks that fail due to "response timeout," the rule can specify "retry 3 times, with an interval of 200 milliseconds each time."

[0089] For example, suppose the task "Read Engine Data" returns a negative response code "Response Timeout" due to bus communication interference. The exception handling engine queries the policy library and matches the rule: "Task Type = Read Data; Failure Reason = Timeout; Handling = Retry (Number of Trials: 2, Interval: 150ms)". Based on this, the engine resets the task status and puts it back into the scheduling pool after 150 milliseconds. If it succeeds after two retries, the task status is updated to "Success". If it still fails, according to the rule, its status is eventually updated to "Failure".

[0090] In one possible embodiment, the method of this application further includes: D1. Generate a log file based on the execution logs of multiple atomic diagnostic tasks. The log file includes the start and end times of each atomic diagnostic task, the actual channels occupied, and the execution status. D2. Based on the log file, update the estimated execution time and task dependency rule base for each atomic diagnostic task.

[0091] In D1, the automotive diagnostic equipment synchronously generates execution logs for atomic diagnostic tasks while performing diagnostic jobs. The equipment's execution monitoring unit captures and records a start timestamp based on the system clock when the atomic diagnostic task begins processing by its assigned communication channel controller. After the task is completed and its status is determined, the monitoring unit records an end timestamp. Simultaneously, the monitoring unit records the identifier of the communication channel actually used by the task and its final execution status. This information, including the task identifier, start timestamp, end timestamp, actual channel identifier, and status code, forms a structured log entry. All log entries for atomic diagnostic tasks are cached in memory during job execution and persistently stored in a log file in non-volatile memory after the job ends or periodically.

[0092] For example, in a diagnostic test of the body module, the atomic diagnostic task "Read Left Front Window Status" (ID: T_WIN_LF) began processing via the LIN channel at 10:30:15.123.456 on November 27, 2023, and received a successful response at 10:30:15.678.901. The monitoring unit generated a log entry: Task ID: T_WIN_LF, Start Time: 10:30:15.123.456, End Time: 10:30:15.678.901, Actual Channel: LIN_Body, Status: Success. This entry, along with entries from other tasks, was ultimately written to the log file on the storage device.

[0093] In D2, the diagnostic device includes a data analysis module that optimizes system parameters and rules based on historical log files. This module reads and parses the stored log files, extracting log entry information.

[0094] Regarding updating the estimated execution time of atomic diagnostic tasks, the data analysis module performs the following operations: The module categorizes entries based on task identifiers in the log entries. For tasks within the same category, it calculates the statistical characteristics of the actual execution time values ​​across all historical records. The actual execution time is obtained by subtracting the start time stamp from the end timestamp. The calculated statistical characteristic values, such as the average value after outlier removal, are used to update the estimated execution time parameters for the corresponding task category in an internal device time parameter library.

[0095] Regarding updating the task dependency rule base, the data analysis module performs execution pattern mining and analysis. The module analyzes the log entry sequences of a large number of jobs, using sequence pattern analysis techniques to identify the sequential relationships between frequently occurring and stable atomic diagnostic tasks in historical execution. When the identified sequential relationship meets preset confidence and support thresholds and is not covered by the existing task dependency rule base, the module formalizes it as a candidate dependency rule. After a verification process, this candidate rule can be added to the task dependency rule base, thereby enriching or correcting the system's knowledge of logical constraints between tasks.

[0096] For example, analyzing the logs of the past 1000 diagnostic operations, focusing on tasks related to the engine control unit (ECU). For tasks like "clearing fault codes," calculating the actual duration of 500 historical records yielded a statistical characteristic value of 220 milliseconds. Based on this, the module updated the estimated execution time of "engine control unit - clearing fault codes" in the duration parameter library to 220 milliseconds. Simultaneously, sequence pattern analysis revealed that in log sequences involving software updates, after the successful completion of the "perform pre-programming checks" task, the "erase memory sectors" task almost always followed successfully, and this order occurred with extremely high frequency. The existing rule base might not explicitly define this dependency. Therefore, a candidate timing dependency rule was generated: the erase memory sectors task depends on the successful completion of the pre-programming checks task. This candidate rule was validated and added to the rule base.

[0097] In this way, through the system recording and analysis of execution logs, diagnostic equipment can continuously self-optimize its core scheduling parameters and business rule base. It can adapt to the performance characteristics of different vehicle or network environments, improving scheduling accuracy; and by learning historical task execution patterns, it continuously improves its understanding of the internal logic of complex diagnostic processes, thereby enhancing the automation and intelligence level of task planning, and ultimately improving the overall efficiency and robustness of the diagnostic system.

[0098] The following are embodiments of the apparatus described in this application, which can be used to execute the embodiments of the method described in this application. For details not disclosed in the apparatus embodiments of this application, please refer to the embodiments of the method described in this application.

[0099] Please see Figure 4 This illustration shows a schematic diagram of a vehicle diagnostic device provided in an exemplary embodiment of this application, hereinafter referred to as device 4. Device 4 can be implemented as all or part of an automotive diagnostic device through software, hardware, or a combination of both. Device 4 includes: The decomposition module 401 is used to decompose the diagnostic job input by the user into multiple atomic diagnostic tasks; The construction module 402 is used to construct a DAG for the multiple atomic diagnostic tasks according to a preset task dependency rule library; wherein, the nodes in the DAG represent atomic diagnostic tasks, and the directed edges represent the execution dependencies between atomic diagnostic tasks. The determination module 403 is used to determine the ECU corresponding to each of the plurality of atomic diagnostic tasks, and to determine the communication channel where each ECU is located; The generation module 404 is used to generate a set of ready tasks by sorting the at least one ready task in the ready state of the DAG monitoring according to a preset sorting rule. The allocation module 405 is used to allocate each ready task in the ready task set to the task queue of its respective communication channel for execution; The execution module 406 is used to concurrently execute ready tasks in the task queues corresponding to different communication channels, and to sequentially execute ready tasks in the task queues corresponding to the same communication channel.

[0100] For further details regarding the implementation of the above-mentioned technical solutions by each module in the diagnostic device for the vehicle, please refer to the description of the vehicle diagnostic method provided in the above-mentioned embodiments of the invention, which will not be repeated here.

[0101] It should be noted that the device 4 provided in the above embodiments is only illustrated by the division of the above functional modules when performing the vehicle diagnostic method. In actual applications, the above functions can be assigned to different functional modules as needed, that is, the internal structure of the device can be divided into different functional modules to complete all or part of the above functions. In addition, the vehicle diagnostic device and the vehicle diagnostic method embodiments provided in the above embodiments belong to the same concept, and the implementation process is detailed in the method embodiments, which will not be repeated here.

[0102] The sequence numbers of the embodiments in this application are for descriptive purposes only and do not represent the superiority or inferiority of the embodiments.

[0103] See Figure 5 The diagram shown is a schematic of a computer storage medium provided in an embodiment of this application. The computer storage medium can store multiple instructions (i.e., ... Figure 5 The computer program shown above), the instructions are adapted to be loaded and executed by a processor as described above. Figure 2 The method steps of the illustrated embodiment can be found in the following documentation for detailed execution. Figure 2 The specific details of the illustrated embodiments will not be elaborated here.

[0104] This application also provides a computer program product that stores at least one instruction, which is loaded and executed by the processor to implement the vehicle diagnostic method as described in the above embodiments.

[0105] Please see Figure 6 This is a schematic diagram of the structure of an automotive diagnostic device provided in an embodiment of this application. Figure 6 As shown, the automotive diagnostic device 600 may include: at least one processor 601, at least one network interface 604, a user interface 603, a memory 605, and at least one communication bus 602.

[0106] The communication bus 602 is used to enable communication between these components.

[0107] The user interface 603 may include input units such as a mouse and a keyboard.

[0108] The network interface 604 may optionally include a standard wired interface or a wireless interface (such as a Wi-Fi interface).

[0109] The processor 601 may include one or more processing cores. The processor 601 connects to various parts within the automotive diagnostic equipment 600 using various interfaces and lines. It executes various functions and processes data by running or executing instructions, programs, code sets, or instruction sets stored in the memory 605, and by calling data stored in the memory 605. Optionally, the processor 601 may be implemented using at least one hardware form of Digital Signal Processing (DSP), Field-Programmable Gate Array (FPGA), or Programmable Logic Array (PLA). The processor 601 may integrate one or a combination of several of the following: Central Processing Unit (CPU), Graphics Processing Unit (GPU), and modem. The CPU primarily handles the operating system, user interface, and applications; the GPU is responsible for rendering and drawing the content to be displayed on the screen; and the modem handles wireless communication. It is understood that the modem may also be implemented as a separate chip without being integrated into the processor 601.

[0110] The memory 605 may include random access memory (RAM) or read-only memory. Optionally, the memory 605 may include a non-transitory computer-readable storage medium. The memory 605 may be used to store instructions, programs, code, code sets, or instruction sets. The memory 605 may include a program storage area and a data storage area, wherein the program storage area may store instructions for implementing an operating system, instructions for at least one function (such as touch function, sound playback function, image playback function, etc.), instructions for implementing the above-described method embodiments, etc.; the data storage area may store data involved in the above-described method embodiments, etc. Optionally, the memory 605 may also be at least one storage device located remotely from the aforementioned processor 601. Figure 6 As shown, the memory 605, which serves as a computer storage medium, may include an operating system, a network communication module, a user interface module, and application programs.

[0111] exist Figure 6 In the automotive diagnostic device 600 shown, the user interface 603 is mainly used to provide an input interface for the user and to acquire user input data; while the processor 601 can be used to call the application program stored in the memory 605 and specifically execute, such as... Figure 2 The method shown can be referred to for details. Figure 2 As shown, it will not be elaborated further here.

[0112] Those skilled in the art will understand that all or part of the processes in the above embodiments can be implemented by a computer program instructing related hardware. The program can be stored in a computer-readable storage medium, and when executed, it can include the processes of the embodiments of the above methods. The storage medium can be a magnetic disk, optical disk, read-only memory, or random access memory, etc.

[0113] The above-disclosed embodiments are merely preferred embodiments of this application and should not be construed as limiting the scope of this application. Therefore, any equivalent variations made in accordance with the claims of this application shall still fall within the scope of this application.

Claims

1. A method for diagnosing a vehicle, characterized in that, The method includes: Decompose the diagnostic job input by the user into multiple atomic diagnostic tasks; Based on a preset task dependency rule base, a Directed Acyclic Graph (DAG) is constructed for the multiple atomic diagnostic tasks; wherein, the nodes in the DAG represent atomic diagnostic tasks, and the directed edges represent the execution dependencies between atomic diagnostic tasks. Identify the ECU corresponding to each of the multiple atomic diagnostic tasks, and determine the communication channel of each ECU; The DAG monitors at least one ready task in a ready state, and generates a ready task set by sorting the at least one ready task according to a preset sorting rule. Each ready task in the ready task set is assigned to the task queue of its respective communication channel for execution; It concurrently executes ready tasks in the task queues corresponding to different communication channels, and sequentially executes ready tasks in the task queues corresponding to the same communication channel.

2. The vehicle diagnostic method according to claim 1, characterized in that, The step of constructing a Directed Acyclic Graph (DAG) for the multiple atomic diagnostic tasks based on a preset task dependency rule base includes: Based on the temporal dependency rules, data dependency rules, and security mutual exclusion dependency rules in the preset task dependency rule base, determine the sequential relationship between any two atomic diagnostic tasks among the multiple atomic diagnostic tasks; A DAG is constructed for the multiple atomic diagnostic tasks based on the aforementioned sequential relationship.

3. The vehicle diagnostic method according to claim 1, characterized in that, The at least one ready task in the DAG monitoring ready state includes: Iterate through the states of each node in the DAG; For each node, check its own status to see if it is "not executed" and check the status of all its direct predecessor nodes to see if it is "successful". If so, the atomic diagnostic task associated with that node will be designated as a ready task.

4. The vehicle diagnostic method according to claim 3, characterized in that, The step of sorting the at least one ready task according to a preset sorting rule to generate a ready task set includes: Prioritize atomic diagnostic tasks with higher security levels; or, Prioritize atomic diagnostic tasks with low real-time load on the corresponding communication channel; or, Prioritize atomic diagnostic tasks with shorter estimated execution times.

5. The vehicle diagnostic method according to claim 1, characterized in that, Also includes: When an atomic diagnostic task fails, all subsequent tasks for that atomic diagnostic task are determined based on the DAG. Set all subsequent tasks to a blocked state; According to the preset strategy, the atomic diagnostic task is retried or skipped.

6. The vehicle diagnostic method according to claim 1, characterized in that, The method further includes: A log file is generated based on the execution logs of the multiple atomic diagnostic tasks. The log file includes the start and end times of each atomic diagnostic task, the actual channels occupied, and the execution status. Based on the log file, update the estimated execution time of each atomic diagnostic task and the task dependency rule base.

7. The vehicle diagnostic method according to claim 1, characterized in that, The process of decomposing the user-input diagnostic job into multiple atomic diagnostic tasks includes: Based on the atomic task template library corresponding to the unified diagnostic service protocol, the diagnostic job is decomposed into multiple atomic diagnostic tasks.

8. A diagnostic device for a vehicle, characterized in that, include: The decomposition module is used to break down the diagnostic job input by the user into multiple atomic diagnostic tasks; The construction module is used to construct a Directed Acyclic Graph (DAG) for the multiple atomic diagnostic tasks according to a preset task dependency rule library; wherein, the nodes in the DAG represent atomic diagnostic tasks, and the directed edges represent the execution dependencies between atomic diagnostic tasks. The determination module is used to determine the ECU corresponding to each of the multiple atomic diagnostic tasks, and to determine the communication channel where each ECU is located; The generation module is used to generate a set of ready tasks by sorting the at least one ready task in the ready state of the DAG monitoring according to a preset sorting rule. The allocation module is used to allocate each ready task in the ready task set to the task queue of its respective communication channel for execution; The execution module is used to concurrently execute ready tasks in the task queues corresponding to different communication channels, and to sequentially execute ready tasks in the task queues corresponding to the same communication channel.

9. A computer storage medium, characterized in that, The computer storage medium stores a plurality of instructions adapted for loading by a processor and executing the steps of the diagnostic method for the vehicle as described in any one of claims 1 to 7.

10. An automotive diagnostic device, characterized in that, include: A processor and a memory; wherein the memory stores a computer program adapted to be loaded by the processor and to execute the steps of the diagnostic method for the vehicle as claimed in any one of claims 1 to 7.

Images