Diagnostic control method and system for vehicle, vehicle diagnostic device and storage medium

Abstract

The application discloses a vehicle diagnosis control method and system, a vehicle diagnosis device and a storage medium. The control method comprises the following steps: in response to a diagnosis request of a vehicle to be diagnosed, obtaining diagnosis operation and vehicle model configuration data of the vehicle; analyzing the diagnosis operation to obtain a data item set comprising a plurality of target node identifiers and corresponding diagnosis tasks; constructing a vehicle multi-bus topology model comprising the correspondence between each target node identifier and a physical bus based on the vehicle model configuration data; dividing each data item in the data item set into a corresponding physical bus group according to the vehicle multi-bus topology model; sending a synchronous trigger instruction to each physical bus group corresponding channel executor to trigger each channel executor to execute the diagnosis task in the corresponding group on the corresponding physical bus; receiving response data returned by each physical bus group, and generating a synchronous diagnosis result.

Description

Technical Field

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

[0002] Currently, mainstream intelligent electric vehicles generally adopt a centralized electronic and electrical architecture that integrates multiple domains. This architecture divides the vehicle's functions into several logical domains, typically including the powertrain domain, body domain, and intelligent driving domain. Each domain controller connects to a heterogeneous onboard communication bus based on its functional real-time requirements, bandwidth needs, and security level, and cross-domain data routing and protocol conversion are achieved through gateway nodes.

[0003] However, in vehicle-level diagnostic applications, existing diagnostic protocols generally rely on a serial polling mechanism: the diagnostic master node sequentially traverses each bus network, initiates a diagnostic request to each controller, and must strictly wait for its response before initiating the access process for the next controller. This serial execution mode results in a lengthy and inefficient vehicle-level diagnostic cycle. Summary of the Invention

[0004] In view of this, embodiments of this application provide a vehicle diagnostic control method, system, vehicle diagnostic equipment, and storage medium, which can effectively solve the problem in the prior art of how to enable cross-domain diagnostic tasks to be initiated and executed concurrently on the physical bus in a heterogeneous multi-bus vehicle network environment.

[0005] In a first aspect, embodiments of this application provide a vehicle diagnostic control method, the method comprising: In response to a diagnostic request from a vehicle to be diagnosed, obtain the vehicle's diagnostic tasks and vehicle configuration data; The diagnostic task is parsed to obtain a set of data items containing multiple target node identifiers and corresponding diagnostic tasks; A vehicle multi-bus topology model is constructed based on the vehicle configuration data. The vehicle multi-bus topology model includes the correspondence between the identifiers of each target node and the physical bus. Each data item in the data item set is assigned to a corresponding physical bus group according to the vehicle multi-bus topology model; A synchronization trigger command is sent to the channel actuators corresponding to each physical bus group to trigger each channel actuator to execute the diagnostic task within its group on its respective physical bus; Receive response data returned by each of the physical bus groups and generate synchronization diagnostic results.

[0006] In some embodiments, it also includes: Obtain the actual initiation time of the diagnostic task corresponding to each physical bus group; Based on each actual initiation time, calculate the initiation time deviation between each physical bus group; Based on the initiation time deviation, update the transmission offset corresponding to each physical bus group; The updated send offset will be applied to the generation of the next synchronization trigger command.

[0007] In some embodiments, constructing a vehicle multi-bus topology model based on the vehicle configuration data includes: The vehicle configuration data is parsed to obtain the mapping relationship between the target node identifier and each physical bus, as well as the routing path information between each target node identifier and the gateway node; The vehicle multibus topology model is constructed based on the mapping relationship and the routing path information.

[0008] In some embodiments, dividing each data item in the data item set into a corresponding physical bus group according to the vehicle multi-bus topology model includes: For each of the data items, the corresponding target node identifier is determined based on the vehicle multi-bus topology model to determine whether it needs to pass through the gateway node; The diagnostic task corresponding to the data item that needs to pass through the gateway node is encapsulated into a transparent frame. The target address of the transparent frame is set to the logical address of the gateway node. The payload of the transparent frame includes the identifier of the corresponding target node and the diagnostic task. Based on the physical bus to which each data item belongs, each data item and its corresponding transparent frame are assigned to the corresponding physical bus group.

[0009] In some embodiments, sending a synchronization trigger command to the channel actuator corresponding to each of the physical bus groups includes: Establish a global time base; Based on the transmission characteristics of each physical bus and the routing path information of each data item as represented by the vehicle multi-bus topology model, the transmission offset corresponding to each data item is determined. Based on the global time base and the transmission offset corresponding to each data item, a synchronization trigger command is generated. The synchronization trigger command is sent to the channel actuator corresponding to each physical bus group.

[0010] In some embodiments, receiving response data returned by each of the physical bus groups and generating synchronization diagnostic results includes: Receive response data returned by each of the physical bus groups; Mark the corresponding local reception time for each of the aforementioned response data; Based on the timestamp of the synchronization trigger instruction corresponding to each response data and the sending offset of the corresponding data item, the actual initiation time of the diagnostic task corresponding to each response data is determined. The response data, the corresponding local receiving time, and the actual initiation time are used as the synchronization diagnosis results.

[0011] In some embodiments, determining the transmission offset corresponding to each of the data items includes: Identify whether each data item needs to pass through the gateway node; For data items that need to pass through the gateway node, the corresponding routing delay is determined based on the routing path information represented by the vehicle multi-bus topology model. The routing delay is included as a component of the transmission offset corresponding to the data item.

[0012] Secondly, embodiments of this application provide a vehicle diagnostic control system, including: The acquisition module is used to acquire the diagnostic operation and vehicle configuration data of the vehicle in response to the diagnostic request of the vehicle to be diagnosed. The parsing module is used to parse the diagnostic job to obtain a set of data items containing multiple target node identifiers and corresponding diagnostic tasks; A construction module is used to construct a vehicle multi-bus topology model based on the vehicle configuration data. The vehicle multi-bus topology model includes the correspondence between the identifiers of each target node and the physical bus. The partitioning module is used to partition each data item in the data item set into the corresponding physical bus group according to the vehicle multi-bus topology model. The sending module is used to send a synchronization trigger command to the channel actuators corresponding to each physical bus group, so as to trigger each channel actuator to execute the diagnostic task within its group on its corresponding physical bus; The generation module is used to receive the response data returned by each of the physical bus groups and generate synchronous diagnostic results.

[0013] Thirdly, embodiments of this application provide a vehicle diagnostic device, the vehicle diagnostic device comprising: a processor and a memory, the memory storing a computer program, and the processor executing the computer program to implement the vehicle diagnostic control method described in the first aspect.

[0014] Fourthly, embodiments of this application provide a computer-readable storage medium storing a computer program, which, when executed by a processor, implements the steps of the vehicle diagnostic control method described in the first aspect.

[0015] The embodiments of this application have the following beneficial effects: The vehicle diagnostic control method of this application includes: responding to a diagnostic request from a vehicle to be diagnosed, acquiring the vehicle's diagnostic task and vehicle model configuration data; parsing the diagnostic task to obtain a data item set containing multiple target node identifiers and corresponding diagnostic tasks; constructing a vehicle multi-bus topology model based on the vehicle model configuration data, the vehicle multi-bus topology model including the correspondence between each target node identifier and a physical bus; dividing each data item in the data item set into a corresponding physical bus group according to the vehicle multi-bus topology model; sending a synchronization trigger command to the channel actuator corresponding to each physical bus group to trigger each channel actuator to execute the diagnostic task within its group on its corresponding physical bus; receiving response data returned by each physical bus group and generating a synchronous diagnostic result. The diagnostic control method of this application enables the simultaneous initiation and concurrent execution of cross-domain diagnostic tasks on the physical bus, greatly shortening the diagnostic cycle. Attached Figure Description

[0016] To more clearly illustrate the technical solutions of the embodiments of this application, the accompanying drawings used in the embodiments will be briefly introduced below. It should be understood that the following drawings only show some embodiments of this application and should not be regarded as a limitation of the scope. For those skilled in the art, other related drawings can be obtained based on these drawings without creative effort.

[0017] Figure 1 A schematic diagram of a vehicle diagnostic control system according to an embodiment of this application is shown; Figure 2 A first flowchart of a vehicle diagnostic control method according to an embodiment of this application is shown; Figure 3 A second flowchart of a vehicle diagnostic control method according to an embodiment of this application is shown; Figure 4 A third flowchart of a vehicle diagnostic control method according to an embodiment of this application is shown; Figure 5 A fourth flowchart of the vehicle diagnostic control method according to an embodiment of this application is shown; Figure 6 A fifth flowchart of the vehicle diagnostic control method according to an embodiment of this application is shown; Figure 7 A sixth flowchart of the vehicle diagnostic control method according to an embodiment of this application is shown; Figure 8 The diagram illustrates the seventh process flow of the vehicle diagnostic control method according to an embodiment of this application. Detailed Implementation

[0018] The technical solutions in 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, and not all embodiments.

[0019] The components of the embodiments of this application described and illustrated in the accompanying drawings can be arranged and designed in a variety of different configurations. Therefore, the following detailed description of the embodiments of this application provided in the drawings is not intended to limit the scope of the claimed application, but merely to illustrate selected embodiments of the application. All other embodiments obtained by those skilled in the art based on the embodiments of this application without inventive effort are within the scope of protection of this application.

[0020] In the following text, the terms "comprising," "having," and their cognates, which may be used in various embodiments of this application, are intended only to indicate a particular feature, number, step, operation, element, component, or combination thereof, and should not be construed as primarily excluding the presence of one or more other features, numbers, steps, operations, elements, components, or combinations thereof, or adding the possibility of one or more combinations thereof. Furthermore, the terms "first," "second," "third," etc., are used only for distinguishing descriptions and should not be construed as indicating or implying relative importance.

[0021] Unless otherwise specified, all terms used herein (including technical and scientific terms) shall have the same meaning as commonly understood by one of ordinary skill in the art to which the various embodiments of this application pertain. Terms (such as those defined in commonly used dictionaries) shall be interpreted as having the same meaning as in their contextual meaning in the relevant technical field and shall not be construed as having an idealized or overly formal meaning, unless clearly defined in the various embodiments of this application.

[0022] The following detailed description of some embodiments of this application is provided in conjunction with the accompanying drawings. Unless otherwise specified, the following embodiments and features can be combined with each other.

[0023] Modern intelligent electric vehicles generally adopt a multi-domain isolation architecture, typically distributed across a powertrain domain, a body domain, and an intelligent driving domain. The powertrain domain encompasses the vehicle controller, motor controller, and battery management system, deployed on a high-speed CAN FD bus or in-vehicle Ethernet channel. The body domain includes the body control module, seat controller, and window controller, primarily operating on a local area network (LAN) channel and a local interconnect network channel. The intelligent driving domain includes cameras, radar, and domain controllers, communicating via in-vehicle Ethernet using the DoIP protocol. In critical scenarios such as after-sales testing, final inspection on the production line, and fault reproduction, unified and reliable health diagnostics of the entire vehicle are required. However, existing diagnostic technologies either use a serial polling method to scan each bus sequentially, waiting for one controller to respond before accessing the next, resulting in excessively long vehicle-level diagnostic times; or, while there are simple concurrent implementations that start independent threads for each bus, they lack cross-bus collaborative scheduling mechanisms, causing high-priority tasks to be blocked by low-speed tasks, and multiple requests being forwarded simultaneously through the same gateway node, leading to resource contention and queue congestion, response delays, and even frequent packet loss.

[0024] This application provides a vehicle diagnostic control method, system, vehicle diagnostic equipment, and storage medium, aiming to solve the above-mentioned problems. Figure 1 This illustration shows a structural diagram of a vehicle diagnostic control system according to an embodiment of this application. The vehicle display control system 100 includes an acquisition module 110, a parsing module 120, a construction module 130, a partitioning module 140, a sending module 150, and a generation module 160. The acquisition module 110 is used to acquire vehicle diagnostic tasks and vehicle model configuration data in response to a diagnostic request from a vehicle to be diagnosed. The parsing module 120 is used to parse the diagnostic tasks to obtain a data item set containing multiple target node identifiers and corresponding diagnostic tasks. The construction module 130 is used to construct a vehicle multi-bus topology model based on the vehicle model configuration data. The vehicle multi-bus topology model includes the correspondence between each target node identifier and a physical bus. The partitioning module 140 is used to partition each data item in the data item set into a corresponding physical bus group according to the vehicle multi-bus topology model. The sending module 150 is used to send a synchronization trigger command to the channel actuators corresponding to each physical bus group to trigger each channel actuator to execute the diagnostic task within its group on its corresponding physical bus. The generation module 160 is used to receive the response data returned by each physical bus group and generate a synchronous diagnostic result.

[0025] This application achieves near-time synchronous acquisition across the power domain, body domain, and intelligent driving domain, with synchronization error controlled at the millisecond level, meeting the data consistency requirements for functional safety verification and vehicle status correlation analysis; it maximizes the parallel capability of multiple buses, improving diagnostic efficiency by more than 50%; it decouples the differences between heterogeneous buses such as CAN, low-speed bus, and Ethernet, allowing each bus group to schedule tasks independently without blocking each other; it is compatible with existing UDS diagnostic protocols and gateway pass-through mechanisms, requiring no modification to controller firmware or underlying communication drivers, and possesses good engineering adaptability and industrialization foundation.

[0026] It should be noted that the system architecture disclosed in this embodiment corresponds one-to-one with the following vehicle diagnostic control methods. All technical features and optional implementation methods described in the vehicle diagnostic control methods are applicable to this system embodiment, enabling the same technical functions and achieving consistent technical effects. The implementation process and operating logic of this control method will be further explained below with reference to specific embodiments.

[0027] Figure 2 A schematic flowchart of a vehicle diagnostic control method according to an embodiment of this application is shown. Exemplarily, the diagnostic control method includes S101-S106: S101, in response to a diagnostic request from the vehicle to be diagnosed, obtains the vehicle's diagnostic work and model configuration data.

[0028] In response to a diagnostic request from a user or system-generated vehicle, the system loads the diagnostic task and vehicle configuration data for the vehicle. This configuration data is a structured dataset pre-set by the OEM during the vehicle design finalization phase, containing static topology information of the vehicle's communication system. Based on this vehicle configuration data, the system constructs three fundamental data structures: a bus resource pool, a controller affiliation mapping, and a domain labeling system. The bus resource pool lists all available physical communication channels on the vehicle, including controller LAN channels, local interconnect network channels, and in-vehicle Ethernet channels, and labels each channel with its bandwidth capacity, maximum concurrent connections, and whether it shares the same gateway node with other channels. The controller affiliation mapping establishes the correspondence between each controller's logical address and its associated physical bus, indicating whether the controller needs to forward messages through a gateway node. The domain labeling system assigns functional domain attributes to each controller, including powertrain domain, body domain, and intelligent driving domain. These attributes are directly derived from the vehicle's electrical and electronic architecture design document and reflect the controller's actual affiliation within the overall vehicle functional system.

[0029] This step provides a unified, accurate, and reusable underlying data foundation for the entire diagnostic control method, enabling subsequent task parsing, grouping, and scheduling to be based on the real vehicle architecture, thus avoiding synchronization failures or resource misallocations caused by model distortion.

[0030] S102, parse the diagnostic task to obtain a set of data items containing multiple target node identifiers and corresponding diagnostic tasks.

[0031] The system parses diagnostic jobs into a synchronous task group, which includes a task group name, a task list, and a synchronization mode. The task group name is a unique identifier for the operation of this synchronous task group, used for scenario marking and tracing in the diagnostic log. It also supports calling predefined standard job templates, eliminating the need for users to repeatedly configure the controller list. The task list is a collection of data items, each containing a target node identifier and corresponding diagnostic service and functional domain attributes. The target node identifier is the controller's logical address in the vehicle network. This address is used to query the controller's attribution mapping to determine its physical bus and whether it needs to be forwarded through a gateway node. The diagnostic service adopts a unified diagnostic service protocol format, consisting of a service identifier and a data identifier, used to specify reading specific parameters or performing specific diagnostic functions.

[0032] The functional domain attribute can be set to powertrain domain, body domain, or intelligent driving domain. This attribute is consistent with the attribute of the corresponding controller in the domain label system and is used to achieve domain-level group management, priority scheduling, and fault isolation during task execution. The synchronization mode is set to time alignment, meaning that all diagnostic tasks within this task group must be initiated as simultaneously as possible on the timeline. To achieve this, the corresponding transmission offset needs to be calculated for each task based on the bandwidth characteristics of each channel in the bus resource pool and the routing path information of each controller in the controller affiliation mapping. This is to compensate for the transmission delay differences of different physical buses and the forwarding delay introduced by the gateway node, ultimately achieving coordinated response of multiple domain controllers within the same millisecond-level time window.

[0033] S103, construct a vehicle multi-bus topology model based on vehicle configuration data. The vehicle multi-bus topology model includes the correspondence between the identifiers of each target node and the physical bus.

[0034] This step involves parsing the vehicle configuration data to extract the mapping relationships between controller logical addresses and various physical buses, as well as the routing path information between gateway node logical addresses and each controller. The mapping relationships clarify which physical bus—controller LAN channel, local interconnection network channel, or vehicle Ethernet channel—each controller logical address belongs to. The routing path information clarifies which gateway node a controller's message must pass through when it is not directly connected to the physical bus accessed by the diagnostic device, and the logical address of that gateway node on the corresponding physical bus.

[0035] Based on the above information, the system constructs a vehicle multi-bus topology model. This model fully expresses the connection relationships between each controller and the physical bus, as well as the forwarding paths formed between controllers through gateway nodes, in a structured manner. This model is the sole basis for task grouping, synchronization offset calculation, and transparent frame encapsulation, ensuring that diagnostic tasks can be accurately allocated to the corresponding physical bus group according to the actual vehicle communication links, and providing deterministic routing target addresses and forwarding paths for tasks that need to be forwarded through gateway nodes.

[0036] For example, in one implementation, such as Figure 3 As shown, constructing a vehicle multi-bus topology model based on vehicle configuration data includes the following sub-steps: S201 parses vehicle configuration data to obtain the mapping relationship between target node identifiers and each physical bus, as well as the routing path information between each target node identifier and the gateway node.

[0037] The system reads the structured fields in the vehicle configuration data, extracts the mapping relationship between the target node identifier and the physical bus, and lists the physical bus name to which each controller logical address belongs in the form of key-value pairs, such as the controller LAN channel, local interconnection network channel or vehicle Ethernet channel; it also extracts the routing path information between the gateway node identifier and the target node identifier, which records the gateway node logical address and its physical bus when each controller logical address needs to be forwarded in the form of a path list.

[0038] S202, constructs a vehicle multi-bus topology model based on mapping relationships and routing path information.

[0039] The system organizes the extracted mapping relationships and routing path information into a bidirectional association graph. Nodes in the graph include all physical buses, all controller logical addresses, and all gateway node logical addresses, while edges represent connection or forwarding relationships. For directly connected controllers, a direct connection edge is established between their node and their corresponding physical bus node. For controllers requiring forwarding through a gateway node, a forwarding edge is established between their node and the gateway node, and the gateway node then establishes a connection edge with its connected physical bus node. This graph structure comprehensively reflects the access location of each controller at the physical layer, the relay role of each gateway node in the communication path, and the set of terminal nodes carried by each physical bus. This model supports rapid lookup of any controller's path to its corresponding physical bus, routing gateway, and forwarding hop count within microseconds, providing deterministic support for task grouping and synchronization offset calculation.

[0040] S104, divide each data item in the data item set into the corresponding physical bus group according to the vehicle multi-bus topology model.

[0041] This step uses the physical bus as the sole grouping criterion, without dividing based on functional domain attributes, to ensure that all tasks within the same physical bus group share the same underlying transmission medium and bandwidth resources.

[0042] The diagnostic software iterates through each diagnostic task, querying the vehicle's multi-bus topology model based on its target node identifier to determine the physical bus to which the target node belongs under the current vehicle configuration. For cases where a target node is connected to multiple physical buses simultaneously, the decision logic is based on the channel priority order preset in the vehicle configuration data. This order is defined by the OEM during the vehicle design phase, specifying the preferred and backup diagnostic channels for each target node. When the user does not specify a channel, the scheduler defaults to the preferred diagnostic channel to ensure maximum communication bandwidth and minimum transmission latency. When a diagnostic task involves reading a large amount of data, the system forces the selection of the in-vehicle Ethernet channel for execution. When a diagnostic task involves control commands with high real-time requirements and the target node has a mapping on the Controller Area Network (CAN) channel, the system selects the CAN channel for execution. Once a diagnostic session is established on a physical bus, all subsequent tasks within the same synchronous task group are locked to execute on that physical bus to avoid interruptions or loss of status due to cross-bus switching. This grouping method strictly binds diagnostic tasks to physical communication resources, providing a deterministic resource allocation basis for subsequent synchronous triggering and concurrent execution, preventing different bus tasks from blocking each other, and ensuring that high-priority tasks are not delayed by low-speed bus tasks.

[0043] Furthermore, after determining the physical bus to which the target node belongs under the current vehicle configuration, the system determines whether the target node needs to be routed through the gateway node based on the vehicle's multi-bus topology model. For target nodes that do not need to be routed through the gateway node, their diagnostic tasks are directly assigned to their respective physical bus group. For target nodes that need to be routed through the gateway node, their diagnostic tasks are encapsulated into transparent frames. The target address of the transparent frame is set to the logical address of the gateway node on the corresponding physical bus. The payload of the transparent frame contains the logical address of the target node and diagnostic service instructions. The gateway node does not perform semantic parsing of the payload content; it only performs protocol conversion and forwarding operations. All encapsulated transparent frames have the same affiliation with their respective physical bus groups and are included in the task queue of that physical bus group. This partitioning ensures that all tasks within the same physical bus group are executed through the same physical channel, avoiding cross-bus resource contention. At the same time, it ensures that tasks requiring routing still logically belong to their original bus channel, providing a prerequisite for subsequent unified scheduling and synchronous triggering.

[0044] For example, in one implementation, such as Figure 4 As shown, S104 includes the following sub-steps: S301 determines, based on the vehicle multi-bus topology model, whether the corresponding target node identifier needs to pass through the gateway node for each data item.

[0045] The system identifies the target node for each diagnostic task and queries its routing path information in the vehicle's multi-bus topology model. If the target node is not directly connected to the physical bus accessed by the diagnostic device, the model records a clear gateway node logical address and its corresponding physical bus; in this case, the task is determined to require routing through the gateway node. If the target node is directly connected to the physical bus accessed by the diagnostic device, the task is determined not to require routing through the gateway node. This determination is a prerequisite for transparent frame encapsulation and transmission offset calculation, ensuring that the system can accurately identify which tasks require additional forwarding path compensation.

[0046] S302, the diagnostic task corresponding to the data item that needs to pass through the gateway node is encapsulated into a transparent transmission frame. The target address of the transparent transmission frame is set to the logical address of the gateway node. The payload of the transparent transmission frame includes the identifier of the corresponding target node and the diagnostic task.

[0047] For diagnostic tasks determined to require routing through a gateway node, the system constructs a transparent frame. This transparent frame follows a multi-layer encapsulation specification of the Controller Area Network (CAN) transmission protocol and the Local Interconnect Network (LIN) transmission protocol. The outermost layer is the standard frame format of the CAN channel, the middle layer contains multi-frame addressing information, and the innermost layer contains diagnostic instructions in the Unified Diagnostic Service Protocol (UDP) format. The target address of the transparent frame is set to the logical address of the gateway node on the CAN channel, which is derived from the definition of the gateway node in the vehicle configuration file. The payload of the transparent frame fully contains the logical address of the target node and the diagnostic instructions in the UDP format. After receiving the transparent frame, the gateway node does not perform any semantic parsing of the payload content; it only performs protocol conversion and forwarding operations, sending the payload unchanged to the target node through the LPN channel. This encapsulation mechanism allows the diagnostic tool to transparently transmit cross-bus diagnostic requests without understanding the internal logic of the gateway node, ensuring the integrity and compatibility of diagnostic functions in heterogeneous network environments.

[0048] S303 allocates each data item and its corresponding transparent frame to the corresponding physical bus group according to the physical bus to which each data item belongs.

[0049] Diagnostic tasks deemed to require no routing, along with their generated pass-through frames, are categorized according to the physical bus to which their target nodes belong. All tasks and pass-through frames belonging to the same Controller Area Network (CAN) channel form one physical bus group; all tasks and pass-through frames belonging to the same Local Interconnect Network (HIBN) channel form another physical bus group; and all tasks and pass-through frames belonging to the same Automotive Ethernet (AutoN) channel form a third physical bus group. Even if two target nodes belong to the same CAN channel but are located in different network segments, as long as their routing paths both point to the same gateway node, they are still assigned to the same physical bus group. This is because all packets are ultimately sent through the physical transceiver of that CAN channel and are uniformly included in the channel's bandwidth arbitration and load management.

[0050] Furthermore, if a physical channel is fully loaded, some tasks can be migrated to an idle channel when the controller supports multi-channel access and the spare channel is idle.

[0051] This allocation method ensures that physical layer resource contention is controllable within the group, avoids bus congestion caused by cross-group contention, and provides structural support for the unified issuance of subsequent synchronous triggering instructions and the independent timeout management of each channel actuator.

[0052] S105 sends a synchronization trigger command to the channel actuators corresponding to each physical bus group to trigger each channel actuator to execute the diagnostic tasks within its respective group on its corresponding physical bus.

[0053] This step is the core execution link for achieving time alignment in the entire diagnostic control method. The system configures an independent channel executor for each physical bus group, and each channel executor is bound to a dedicated physical communication interface. This ensures complete decoupling between different bus groups at the hardware access layer, protocol stack processing layer, and resource scheduling layer, avoiding bandwidth contention or timing interference caused by cross-bus coupling. All channel executors run collaboratively with the main scheduler within the same diagnostic device, but each has its own independent thread, independent memory space, and independent timeout management mechanism, ensuring that the failure of a task in any physical bus group will not interrupt or delay the execution of tasks in other physical bus groups.

[0054] For example, in one implementation, such as Figure 5 As shown, sending synchronization trigger commands to the channel actuators corresponding to each physical bus group includes the following sub-steps: S401, establish a global time base.

[0055] Before initiating the synchronous diagnostic process, the system initializes a high-precision timer. This timer, implemented as an independent hardware timer on the motherboard, is suitable for generating microsecond-level deterministic interrupt events. Specifically, this hardware timer is a high-performance event timer whose count is uniformly driven by the system clock of the diagnostic device, independent of the operating system kernel clock or software loop timing, thus eliminating timing deviations caused by scheduling jitter in the general operating system. The timestamp generated by this timer constitutes the global time base for the entire diagnostic control process. All synchronous trigger actions, task initiation time recordings, and response time calculations use this base as the sole reference, ensuring consistency and comparability of time measurements across the physical bus.

[0056] S402 determines the transmission offset corresponding to each data item based on the transmission characteristics of each physical bus and the routing path information of each data item as represented by the vehicle multi-bus topology model.

[0057] The system first queries the vehicle's multi-bus topology model to obtain the transmission characteristics of each physical bus, including the arbitration latency and frame transmission time of the Controller Area Network (CAN) channel, the single-frame transmission period of the Local Interconnect Network (HIBN) channel, and the TCP connection establishment overhead and packet encapsulation latency of the vehicular Ethernet (VEN) channel. Simultaneously, it queries the routing path information of each data item to identify whether it needs to be forwarded through a gateway node and the number of hops and node types in the forwarding path. Based on this, a corresponding transmission offset is calculated for each diagnostic task. This offset is used to compensate for the inherent transmission latency differences between different physical buses and the additional forwarding latency introduced by the gateway node, ensuring that the actual initiation time of all tasks is concentrated within the same millisecond-level time window as much as possible.

[0058] For example, in one implementation, such as Figure 6 As shown, determining the transmission offset corresponding to each data item includes the following sub-steps: S501 identifies whether each data item needs to pass through a gateway node.

[0059] For each diagnostic task, the routing path information stored in the vehicle multi-bus topology model is queried based on its target node identifier. If the target node is not directly connected to the physical bus to which the diagnostic device is connected, the model explicitly records the logical address of the gateway node and its physical bus. In this case, it is determined that the data item needs to be routed through the gateway node. If the target node is directly connected to the physical bus to which the diagnostic device is connected, it is determined that the data item does not need to be routed through the gateway node.

[0060] S502: For data items that need to pass through the gateway node, the corresponding routing delay is determined based on the routing path information represented by the vehicle multi-bus topology model.

[0061] For data items determined to require routing through a gateway node, complete routing path information is extracted from the vehicle multi-bus topology model. This path information includes the gateway node's logical address on the source physical bus, the gateway node's forwarding capability on the target physical bus, and the type and transmission characteristics of the target physical bus. Based on this, the system calculates the routing delay, which includes: the message transmission time of the source physical bus, the queuing and forwarding processing time within the gateway node, the message transmission time of the target physical bus, and the response preparation time of the target controller. The queuing and forwarding processing time within the gateway node is a fixed empirical value derived from the OEM's calibration test results of the gateway node's hardware performance during the vehicle configuration phase and is loaded into the system along with the vehicle configuration file.

[0062] S503 incorporates routing delay as a component of the transmission offset corresponding to a data item.

[0063] The system combines the calculated routing delay with other influencing factors to form the final transmission offset. These factors include the inherent transmission delay of the source physical bus, the historical response fluctuation of the target controller, and the real-time load status of the current physical bus. For data items requiring routing through the gateway node, the routing delay has the highest weight in the transmission offset, ensuring that the triggering time of this task is significantly advanced to offset the systemic lag introduced by the gateway node. For directly connected data items, the transmission offset mainly reflects the transmission delay and historical response fluctuation of the source physical bus. This configuration ensures that the actual initiation time deviation of all data items is strictly controlled within 2 milliseconds, meeting the stringent time consistency requirements of the vehicle status snapshot.

[0064] S403 generates a synchronization trigger command based on the global time base and the transmission offset corresponding to each data item.

[0065] The diagnostic software uses a global time base as a starting point and, combined with the transmission offset calculated for each data item, generates a set of timestamped synchronization trigger instructions. Each synchronization trigger instruction includes the target physical bus group identifier, the precise trigger time of each task within that group, and the complete diagnostic parameters for the corresponding task. This instruction set is organized in memory as a time-ordered queue, with all instruction timestamps relative to the same global time base, ensuring that trigger instructions from different physical bus groups have a logically defined sequence and strict timing constraints.

[0066] S404 sends synchronization trigger commands to the channel actuators corresponding to each physical bus group.

[0067] The system issues synchronization trigger instructions to the corresponding channel executors of each physical bus group through atomic variables in shared memory. This mechanism is CPU instruction-level synchronization, without operating system kernel mode switching, protocol stack encapsulation and parsing overhead, and has the highest determinism and timeliness. Each channel executor is bound to an independent physical CPU core after startup and continuously reads the atomic variable using a spin-wait method. Once the variable value is updated, the cache consistency protocol notifies the executor within nanoseconds, causing it to immediately break out of the waiting loop and begin execution. At the same time, all channel executor threads are set to the highest real-time priority allowed by the operating system, ensuring that they can still preempt CPU resources under high system load and are not affected by scheduling interference from other processes. This sending mechanism ensures that all channel executors can send the first frame message to their respective physical buses within 1 millisecond after receiving the synchronization trigger instruction, ultimately achieving near-simultaneous initiation of all diagnostic tasks on the physical buses, with synchronization errors strictly controlled within 2 milliseconds.

[0068] Furthermore, each channel actuator is dynamically adjusted using an exponentially weighted moving average algorithm. After each diagnostic task completes a full request-response interaction, the corresponding channel actuator immediately collects the round-trip time as... This drives the subsequent three-step update. The first step is the mean update, where the current round-trip time sample value is set to... The previous smoothed mean was The mean will be updated to... The smoothing coefficient Depending on the bus type, a higher coefficient, such as 0.3, is used for high-speed buses to quickly track changes, while a lower coefficient, such as 0.1, is used for low-speed buses to suppress noise.

[0069] The second step is the jitter variance recursion. To save embedded memory, a recursive method is used to calculate the jitter variance. There's no need to store historical sample queues; only the squared value of the previous jitter variance is retained. The recursive formula is: [Jitter Variance Formula]. ,in, This represents the variance of the previous jitter. In engineering implementation, the squared variance value can be stored to avoid square root calculation in each round, and the square root is only performed once when the final synthesis timeout threshold is reached.

[0070] The third step is to synthesize the dynamic timeout threshold by combining the updated mean and standard deviation according to the safety margin. ,in K is the minimum timeout value for the protocol, and K is a multiple of the standard deviation used to control the coverage probability. For example, K equals 2. This is a system scheduling error compensation value, ensuring that the threshold is not lower than the hard requirements of the physical bus protocol, with a value range of 2ms-5ms. The updated timeout threshold is further squeezed within the minimum and maximum timeout intervals specified in the protocol to prevent the threshold from diverging into an unusable range.

[0071] After the synchronization trigger command is issued, all channels simultaneously generate the first frame. This instantaneous bus congestion can cause the initial round-trip time sample value to be abnormally high. To avoid such cold-start spikes increasing statistics and reducing the algorithm's sensitivity to detecting subsequent real anomalies, the channel actuators enforce the use of the protocol's minimum timeout value during the first 3-5 sampling periods. Dynamic timeout threshold updates are not enabled; the complete adaptive update process will only begin after the cold start counter reaches zero.

[0072] Each channel actuator maintains an independent algorithm context, possessing its own smoothing coefficient, standard deviation multiple, cold start counter, and corresponding protocol minimum timeout value and system scheduling error compensation value. This allows different buses to independently and adaptively adjust based on their respective differentiated physical transmission characteristics and channel actuator response fluctuation patterns. When a channel experiences an abnormally high round-trip time due to a sleep wake-up or load surge in its corresponding channel actuator, only the dynamic timeout threshold of that channel will increase accordingly to await a response. The statistics and timeout thresholds of other channels remain completely unaffected. This achieves fault isolation between channels, ensuring that a single channel timeout only triggers retry or error handling for that channel and does not block the concurrent diagnostic processes of other channels.

[0073] S106 receives response data returned by each physical bus group and generates synchronization diagnostic results.

[0074] The heterogeneous response data obtained from distributed concurrent execution are uniformly aggregated into synchronous diagnostic results with strict time semantics. All response data comes from the messages returned by each channel actuator after independently executing tasks on its own physical bus, including multi-frame responses returned by the controller area network channel, single-frame responses returned by the local interconnection network channel, and session-level responses returned by the vehicle Ethernet channel.

[0075] For example, in one implementation, such as Figure 7 As shown, S106 includes the following sub-steps: S601 receives response data returned by each physical bus group.

[0076] The system monitors the physical communication interface of each physical bus group through the corresponding channel actuators, capturing the complete response content immediately upon message arrival. Each channel actuator operates independently on its respective physical bus, employing a protocol stack processing mechanism compatible with that bus: the Controller Area Network (CAN) channel uses the CAN transport protocol for flow control and reassembly; the Local Interconnect Network (HIBN) channel uses a single-frame or simple multi-frame mechanism to complete response parsing; and the Vehicle Ethernet channel establishes a session and receives response data based on the Vehicle Ethernet Diagnostic Protocol. Upon receiving a response, each channel actuator does not perform cross-bus forwarding or merging; instead, it submits the original response data along with its metadata to the system.

[0077] S602 marks the corresponding local reception time for each response data.

[0078] Upon receiving each response data message, the system invokes the global time base to stamp the response data with a local reception time marker accurate to the microsecond level. This marking action is completed within the first nanosecond of receiving the response data, without any intermediate buffering or queuing, ensuring that the timestamp accurately reflects the time when the response message arrived at the system. All local reception times are referenced to the same global time base, eliminating clock drift caused by different physical bus drivers, interrupt handling paths, or memory copy delays, thus providing a unified time coordinate system for subsequent initiation time calculations and deviation analysis.

[0079] S603 determines the actual initiation time of the diagnostic task corresponding to each response data based on the timestamp of the synchronous trigger instruction corresponding to each response data and the sending offset of the corresponding data item.

[0080] The system calculates the absolute time when the task actually sends its first frame on the physical bus, based on the timestamp carried by the generated synchronization trigger command and the pre-calculated and stored transmission offset for that task. This actual initiation time is equal to the timestamp of the synchronization trigger command plus the corresponding transmission offset for that task, and its unit is microseconds, with precision consistent with the global time base.

[0081] S604 uses each response data, the corresponding local reception time, and the actual initiation time as the synchronization diagnosis result.

[0082] The system binds all received response data, the local reception time marked for each response, and the actual initiation time derived from each response, according to task granularity, and encapsulates them into a structured synchronous diagnostic result. This result is output in a standard data format, including the response content, local reception time, actual initiation time, target controller logical address, diagnostic service command, physical bus identifier, and functional domain attributes. This result directly supports advanced applications such as vehicle status snapshots, fault reproduction analysis, and multi-domain correlation diagnostics. The concentration of actual initiation times ensures strong consistency of all data in the time dimension, enabling cross-domain parameters such as vehicle speed in the power domain and door status in the body domain to possess genuine causal analysis value.

[0083] Furthermore, such as Figure 8 As shown, the diagnostic control methods also include S701-S704: S701, obtain the actual initiation time of the diagnostic task corresponding to each physical bus group.

[0084] After calculating all actual initiation times, the system extracts the actual initiation time of each diagnostic task from the synchronous diagnostic results, forming a time series set divided by physical bus group. Each set contains the actual initiation times of all tasks within that physical bus group, all of which are aligned to the same global time base and can be directly compared in terms of differences.

[0085] S702 calculates the startup time deviation between each physical bus group based on each actual startup time.

[0086] The system uses the minimum value among all actual initiation times as the baseline time point, calculates the difference between each of the remaining actual initiation times and this baseline time point, and obtains the time offset of each task relative to the earliest initiating task. Then, it performs grouping and statistical analysis by physical bus group, obtaining the initiation time range, average offset, and maximum deviation value for all tasks within each group. The average offset is used as the initiation time deviation, which directly characterizes the time alignment quality of each physical bus group in this synchronization diagnosis. If the maximum deviation value of a group exceeds 2 milliseconds, it indicates that there is a systemic delay or sudden congestion in that group, and it needs to be included in the health assessment. In the next scheduling, the task grouping will be automatically optimized, postponing non-critical diagnostic tasks in that group or automatically reducing the communication frequency of that group to avoid conflicts.

[0087] S703 updates the transmit offset corresponding to each physical bus group based on the initiation time deviation.

[0088] The system uses the calculated initiation time deviation as a feedback signal to dynamically correct the transmission offset set for each data item. For physical bus groups whose initiation times are generally lagging behind the baseline, the system increases the transmission offset of their next task by a correction value equal to the average initiation time deviation of that group. For physical bus groups with drastic fluctuations in initiation times, the system expands the safety margin of their transmission offset to enhance their ability to adapt to jitter. For physical bus groups with stable and accurate initiation times, their original transmission offset remains unchanged.

[0089] S704 applies the updated send offset to the generation of the next synchronization trigger command.

[0090] Before executing S105 again, the system loads the updated transmission offset into the memory cache as the initial reference value for the transmission offset calculation in S402. This loading action is automatically triggered after the diagnostic job is parsed and before the synchronization trigger command is generated, ensuring that all newly generated synchronization trigger commands carry timing parameters optimized by closed loop. This mechanism enables the diagnostic system to have self-learning capabilities, continuously improving synchronization accuracy under different vehicle models, different gateway architectures, and different bus load conditions, ultimately achieving sub-millisecond stable time alignment and supporting vehicle-level status acquisition and analysis under functional safety requirements.

[0091] In one embodiment, a new energy vehicle manufacturer needs to take a snapshot of the vehicle's status at the final inspection station for archiving factory data. This operation requires acquiring key operating parameters of the power domain, body domain, and intelligent driving domain within the same millisecond-level time window. Specifically, this includes: vehicle speed and motor speed data of the vehicle controller on the controller area network channel; battery state of charge and temperature data of the battery management system on the controller area network channel; door status and lighting status data of the body control module on the local interconnection network channel; and camera online status data of the intelligent driving domain controller on the vehicle Ethernet channel. These four types of data correspond to different controller logical addresses, physical communication channels, and data identifiers, and because the body control module is connected to a low-speed local interconnection network channel, it must be forwarded through a gateway node before it can be accessed by diagnostic equipment.

[0092] Traditional diagnostic software uses a serial polling approach to perform this task: it sequentially sends a request to the vehicle controller and waits for a response, taking 80 milliseconds; then sends a request to the battery management system and waits for a response, taking 70 milliseconds; next, it sends a pass-through frame to the gateway node and waits for a response from the body control module, taking 320 milliseconds; finally, it sends a request to the intelligent driving domain controller and waits for a response, taking 50 milliseconds. The entire process takes a total of 520 milliseconds, and the actual acquisition times of each parameter are scattered over a time span of more than 500 milliseconds, failing to reflect the true coordinated state of the vehicle at any given moment. This results in the factory data lacking value for fault reproduction and multi-domain correlation analysis.

[0093] When the diagnostic control method of this embodiment is implemented in the diagnostic software, it first loads the vehicle configuration data and constructs a vehicle multi-bus topology model. This model clearly records: the Controller Area Network (CAN) channel carries the vehicle controller and battery management system, both of which are directly connected to the diagnostic equipment; the local interconnect network (NAT) channel carries the body control module, and its communication path must pass through the logical address of the gateway node on the CAN channel; the in-vehicle Ethernet channel carries the intelligent driving domain controller, which is directly connected to the diagnostic equipment. This topology model provides a realistic, static, and reusable architectural basis for subsequent task parsing, grouping, and synchronization triggering, ensuring that all scheduling decisions conform to the actual vehicle communication links.

[0094] Based on the vehicle's multi-bus topology model, the diagnostic software parses the user-defined vehicle status snapshot job into synchronous task groups, and divides them into three physical bus groups according to their physical bus affiliation: the first physical bus group consists of tasks belonging to the Controller Area Network (CAN) channel, including diagnostic tasks for the vehicle controller and battery management system; the second physical bus group consists of tasks belonging to the local interconnect network (NAT) channel, including diagnostic tasks for the body control module, which are encapsulated as transparent frames with the destination address set to the gateway node's logical address on the CAN channel; and the third physical bus group consists of tasks belonging to the in-vehicle Ethernet channel, including diagnostic tasks for the intelligent driving domain controller. This grouping method completely decouples the transmission characteristics and protocol stack differences of different physical buses, allowing each group of tasks to be independently scheduled, executed concurrently, and without interference on its respective channel.

[0095] The diagnostic software starts a high-precision timer to establish a global time reference with the diagnostic device's system clock as the sole source, and generates synchronization trigger commands accordingly. At 0 milliseconds, the main scheduler simultaneously sends synchronization trigger signals to the three channel actuators via atomic variables in shared memory. Each channel actuator responds within 1 millisecond of receiving the signal: the onboard Ethernet channel actuator sends a request at 0.2 milliseconds, the controller area network channel actuator sends a parallel request to the vehicle controller and battery management system at 0.3 milliseconds, and the transparent frame corresponding to the local interconnect network channel is sent to the gateway node at 0.5 milliseconds. The actual initiation time deviation of all requests is strictly controlled within 1 millisecond, meeting the core requirement of time alignment.

[0096] Each channel actuator executes its task independently on its respective physical bus: the Controller Area Network (CAN) channel group receives responses from the vehicle controller and battery management system within 80 milliseconds; the Local Interconnect Network (HIN) channel group, after being forwarded by the gateway node, transmits responses from the body control module within 210 milliseconds; and the In-Vehicle Ethernet (IVN) channel group receives responses from the Intelligent Driving Domain Controller within 45 milliseconds. Because the three task groups are completely isolated at the physical layer, there is no contention for shared resources, and the entire execution process is unblocked, queue-free, and without cross-bus waiting. Gateway resource utilization is transformed from a concentrated, instantaneous peak in traditional solutions to a continuously and evenly distributed distribution.

[0097] The diagnostic software collects all response data at 215 milliseconds, marks the local reception time for each response, and deduces the actual initiation time of each task based on the timestamp of the synchronization trigger command and the corresponding transmission offset. All actual initiation times are marked as around 0 milliseconds, with a synchronization error of ±1 millisecond. Finally, a unified diagnostic report is generated, titled "Vehicle Status Snapshot," with a timestamp of 10:00:00:00 on December 29, 2025 (synchronization error ±1 millisecond). Each data point in the report includes its actual initiation time, local reception time, and corresponding functional domain, forming a vehicle-level transient status view with strong time consistency.

[0098] Compared to traditional serial solutions, this embodiment reduces the total diagnostic time from 520 milliseconds to 215 milliseconds, improving efficiency by 59%; compresses data time consistency from spanning 500 milliseconds to within a 2-millisecond time window; enables true concurrent execution of diagnostic tasks in the power domain and body domain; transforms gateway node resource utilization from momentary congestion to stable load; and fully supports various application scenarios such as final inspection on the production line, after-sales diagnostics, and remote OTA, without requiring any modification to the controller firmware or communication protocol, and is fully compatible with the existing vehicle network architecture and unified diagnostic service protocol.

[0099] This application also provides a vehicle diagnostic device, exemplary of which includes a processor and a memory, wherein the memory stores a computer program, and the processor executes the computer program to enable the device to perform the functions of the vehicle diagnostic control method or the various modules in the vehicle diagnostic control system described above.

[0100] The processor can be an integrated circuit chip with signal processing capabilities. The processor can be a general-purpose processor, including at least one of a Central Processing Unit (CPU), Graphics Processing Unit (GPU), Network Processor (NP), Digital Signal Processor (DSP), Application-Specific Integrated Circuit (ASIC), Field-Programmable Gate Array (FPGA), or other programmable logic devices, discrete gate or transistor logic devices, or discrete hardware components. The general-purpose processor can be a microprocessor or any conventional processor, capable of implementing or executing the methods, steps, and logic block diagrams disclosed in the embodiments of this application.

[0101] Memory can be, but is not limited to, Random Access Memory (RAM), Read Only Memory (ROM), Programmable Read-Only Memory (PROM), Erasable Programmable Read-Only Memory (EPROM), and Electrically Erasable Programmable Read-Only Memory (EEPROM). Memory is used to store computer programs, and the processor can execute these programs upon receiving execution instructions.

[0102] This application also provides a computer-readable storage medium for storing the computer program used in the aforementioned vehicle diagnostic equipment. For example, the computer-readable storage medium may include, but is not limited to, various media capable of storing program code, such as a USB flash drive, a portable hard disk, a read-only memory (ROM), a random access memory (RAM), a magnetic disk, or an optical disk.

[0103] In the several embodiments provided in this application, it should be understood that the disclosed apparatus and methods can also be implemented in other ways. The apparatus embodiments described above are merely illustrative. For example, the flowcharts and block diagrams in the accompanying drawings show the architecture, functionality, and operation of possible implementations of apparatus, methods, and computer program products according to various embodiments of this application. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing a specified logical function. It should also be noted that, in alternative implementations, the functions marked in the blocks may occur in a different order than those marked in the drawings. For example, two consecutive blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in the block diagram and / or flowchart, and combinations of blocks in the block diagram and / or flowchart, can be implemented using a dedicated hardware-based system that performs the specified function or action, or using a combination of dedicated hardware and computer instructions.

[0104] In addition, the functional modules or units in the various embodiments of this application can be integrated together to form an independent part, or each module can exist independently, or two or more modules can be integrated to form an independent part.

[0105] If the aforementioned functions are implemented as software functional modules and sold or used as independent products, they can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or a part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a smartphone, personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this application.

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

Claims

1. A diagnostic control method for a vehicle, characterized in that, The method includes: In response to a diagnostic request from a vehicle to be diagnosed, obtain the vehicle's diagnostic tasks and vehicle configuration data; The diagnostic task is parsed to obtain a set of data items containing multiple target node identifiers and corresponding diagnostic tasks; A vehicle multi-bus topology model is constructed based on the vehicle configuration data. The vehicle multi-bus topology model includes the correspondence between the identifiers of each target node and the physical bus. Each data item in the data item set is assigned to a corresponding physical bus group according to the vehicle multi-bus topology model; A synchronization trigger command is sent to the channel actuators corresponding to each physical bus group to trigger each channel actuator to execute the diagnostic task within its group on its respective physical bus; Receive response data returned by each of the physical bus groups and generate synchronization diagnostic results.

2. The vehicle diagnostic control method according to claim 1, characterized in that, Also includes: Obtain the actual initiation time of the diagnostic task corresponding to each physical bus group; Based on each actual initiation time, calculate the initiation time deviation between each physical bus group; Based on the initiation time deviation, update the transmission offset corresponding to each physical bus group; The updated send offset will be applied to the generation of the next synchronization trigger command.

3. The vehicle diagnostic control method according to claim 1, characterized in that, The construction of the vehicle multi-bus topology model based on the vehicle configuration data includes: The vehicle configuration data is parsed to obtain the mapping relationship between the target node identifier and each physical bus, as well as the routing path information between each target node identifier and the gateway node; The vehicle multibus topology model is constructed based on the mapping relationship and the routing path information.

4. The vehicle diagnostic control method according to claim 1, characterized in that, The step of dividing each data item in the data item set into the corresponding physical bus group according to the vehicle multi-bus topology model includes: For each of the data items, the corresponding target node identifier is determined based on the vehicle multi-bus topology model to determine whether it needs to pass through the gateway node; The diagnostic task corresponding to the data item that needs to pass through the gateway node is encapsulated into a transparent frame. The target address of the transparent frame is set to the logical address of the gateway node. The payload of the transparent frame includes the identifier of the corresponding target node and the diagnostic task. Based on the physical bus to which each data item belongs, each data item and its corresponding transparent frame are assigned to the corresponding physical bus group.

5. The vehicle diagnostic control method according to claim 4, characterized in that, Sending synchronization trigger commands to the channel actuators corresponding to each of the physical bus groups includes: Establish a global time base; Based on the transmission characteristics of each physical bus and the routing path information of each data item as represented by the vehicle multi-bus topology model, the transmission offset corresponding to each data item is determined. Based on the global time base and the transmission offset corresponding to each data item, a synchronization trigger command is generated. The synchronization trigger command is sent to the channel actuator corresponding to each physical bus group.

6. The vehicle diagnostic control method according to claim 1, characterized in that, The process of receiving response data returned by each of the physical bus groups and generating synchronization diagnostic results includes: Receive response data returned by each of the physical bus groups; Mark the corresponding local reception time for each of the aforementioned response data; Based on the timestamp of the synchronization trigger instruction corresponding to each response data and the sending offset of the corresponding data item, the actual initiation time of the diagnostic task corresponding to each response data is determined. The response data, the corresponding local receiving time, and the actual initiation time are used as the synchronization diagnosis results.

7. The vehicle diagnostic control method according to claim 5, characterized in that, Determining the transmission offset corresponding to each of the data items includes: Identify whether each data item needs to pass through the gateway node; For data items that need to pass through the gateway node, the corresponding routing delay is determined based on the routing path information represented by the vehicle multi-bus topology model. The routing delay is included as a component of the transmission offset corresponding to the data item.

8. A diagnostic control system for a vehicle, characterized in that, include: The acquisition module is used to acquire the diagnostic operation and vehicle configuration data of the vehicle in response to the diagnostic request of the vehicle to be diagnosed. The parsing module is used to parse the diagnostic job to obtain a set of data items containing multiple target node identifiers and corresponding diagnostic tasks; A construction module is used to construct a vehicle multi-bus topology model based on the vehicle configuration data. The vehicle multi-bus topology model includes the correspondence between the identifiers of each target node and the physical bus. The partitioning module is used to partition each data item in the data item set into the corresponding physical bus group according to the vehicle multi-bus topology model. The sending module is used to send a synchronization trigger command to the channel actuators corresponding to each physical bus group, so as to trigger each channel actuator to execute the diagnostic task within its group on its corresponding physical bus; The generation module is used to receive the response data returned by each of the physical bus groups and generate synchronous diagnostic results.

9. A vehicle diagnostic device, characterized in that, The vehicle diagnostic device includes a processor and a memory, the memory storing a computer program, and the processor executing the computer program to implement the vehicle diagnostic control method according to any one of claims 1-7.

10. A computer-readable storage medium, characterized in that, It stores a computer program that, when executed on a processor, implements the steps of the diagnostic control method for a vehicle according to any one of claims 1-7.

Images