Diagnostic method and apparatus, and vehicle

Abstract

Provided in the present application are a diagnostic method and apparatus, and a vehicle. The method is applied to a first module. The method comprises: receiving first request information sent by a first client, wherein the first request information is used for requesting a target device to execute a first diagnostic service; sending the first request information to the target device; receiving first response information sent by the target device, wherein the first response information is used for instructing the target device to execute the first diagnostic service; and when a second client has established a first diagnostic channel with a first module, ignoring the first response information. By means of the method, a high-priority diagnostic client can be prevented from receiving a diagnostic response for a preempted low-priority client, thereby avoiding a diagnostic abnormality or even a diagnostic failure of the high-priority client.

Description

Diagnostic methods, devices, and vehicles

[0001] This application claims priority to Chinese patent application filed on December 11, 2024, with application number 202411837288.8 and title "Diagnostic Method, Apparatus and Vehicle", the entire contents of which are incorporated herein by reference. Technical Field

[0002] This application relates to the field of vehicles, and more specifically, to a diagnostic method, apparatus, and vehicle. Background Technology

[0003] As smart cars become increasingly common in daily life, users expect them to provide a more comfortable and intelligent experience. Against this backdrop, electronic control technology has gradually penetrated into various vehicle components, significantly improving vehicle performance and comfort. However, with increasingly complex vehicle structures and rising levels of automation, the electronic control systems of the entire vehicle are also becoming more complex, leading to a rise in after-sales diagnostic problems and increasing diagnostic difficulty.

[0004] When multiple diagnostic clients (e.g., remote diagnostics, over-the-air (OTA) upgrades, local diagnostics, and device management) use the diagnostic channel simultaneously, a scenario will arise where electronic control units (ECUs) on the controller area network (CAN) are being diagnosed at the same time. In this case, the vehicle needs to introduce a diagnostic preemption mechanism, whereby a higher-priority diagnostic client can preempt a lower-priority diagnostic client to ensure that only one diagnostic client uses the diagnostic channel at any given time.

[0005] However, after a diagnostic preemption occurs, if the preempted low-priority client has already sent a diagnostic request to the CAN ECU but has not yet received a diagnostic response from the CAN ECU, the high-priority diagnostic client will receive the diagnostic response from the CAN ECU, causing the high-priority client to experience diagnostic anomalies or even diagnostic failures. Summary of the Invention

[0006] This application provides a diagnostic method, apparatus, and vehicle that can prevent high-priority diagnostic clients from receiving diagnostic responses for preempted low-priority clients, thereby avoiding diagnostic anomalies or even diagnostic failures for high-priority clients.

[0007] In a first aspect, a diagnostic method is provided, the method comprising: receiving a first request message sent by a first client, the first request message being used to request a target device to perform a first diagnostic service; sending the first request message to the target device; receiving a first response message sent by the target device, the first response message being a response to the first request message, wherein the first response message is ignored when a second client establishes a first diagnostic channel with a first module.

[0008] In one possible implementation, the establishment of the first diagnostic channel between the second client and the first module can be understood as the second client preempting the second diagnostic channel between the first client and the first module, that is, the second diagnostic channel is released and the first diagnostic channel is established.

[0009] In one possible implementation, the relationship between diagnostic services and diagnostic channels can be understood as follows: diagnostic services transmit and communicate data through diagnostic channels, that is, diagnostic channels are the transmission path or medium through which diagnostic services are realized.

[0010] In one possible implementation, ignoring the first response information can be understood as: the first module stops sending the first response information, or the first module discards the first response information.

[0011] In this embodiment, when the second client establishes a first diagnostic channel with the first module, the first module can ignore the first response information for the first client. This prevents the second client from receiving the first response information after diagnostic preemption, thus avoiding diagnostic anomalies or even diagnostic failures on the second client.

[0012] In conjunction with the first aspect, in some implementations of the first aspect, the first response information includes a first source address, and ignoring the first response information when the second client establishes a first diagnostic channel with the first module includes: ignoring the first response information when the first source address is in an inactive state.

[0013] In this embodiment of the application, it can be determined that the second client has preempted based on the status of the first source address, and then the first response information can be ignored, thereby avoiding the phenomenon that the second client has diagnostic anomalies or even diagnostic failures.

[0014] In conjunction with the first aspect, in some implementations of the first aspect, the first request information includes: a first diagnostic service identifier, the first response message further includes a second diagnostic service identifier, and before ignoring the first response information, the method further includes: determining that the first diagnostic service identifier and the second diagnostic service identifier are consistent.

[0015] In one possible implementation, the consistency of the first diagnostic service identifier and the second diagnostic service identifier can be understood as: the first diagnostic service identifier and the second diagnostic service identifier are completely identical.

[0016] In this embodiment, the diagnostic service identifier carried in the first request information and the first response information are consistent, and the first module ignores the first response information. This processing method helps to improve the accuracy, security, and operational efficiency of information transmission, avoids information confusion and conflict, and thus further prevents the first client from receiving the first response information after a preemption occurs.

[0017] In conjunction with the first aspect, in some implementations of the first aspect, the first request information includes the first source address. Before receiving the first response information sent by the target device, the method further includes: receiving second request information sent by the second client, the second request information being used to request the target device to perform a second diagnostic service, the second request information including a second source address; determining that the priority of the second client is higher than the priority of the first client based on the first source address, the second source address, and a first correspondence relationship, the first correspondence relationship being a correspondence relationship between source address and client priority.

[0018] In one possible implementation, the first correspondence can be pre-stored in the first module.

[0019] In this embodiment, the priority of the second client can be determined to be higher than that of the first client based on the first source address, the second source address, and the first correspondence. This facilitates the establishment of a first diagnostic channel between the first module and the second client based on their respective priorities. This approach helps optimize the allocation of computing resources and ensures that critical diagnostic tasks are processed with priority.

[0020] In conjunction with the first aspect, in some implementations of the first aspect, before receiving the first response information sent by the target device, the method further includes: starting a first timer according to the second request information and sending a waiting response information to the second client; ignoring the first response information includes: ignoring the first response information if the first timer has not expired.

[0021] In this embodiment, when the first module receives the second request information before receiving the first response information, the first module can send a waiting response information to the second client. This effectively prevents the target device from simultaneously receiving both the first and second request information, thus preventing diagnostic failure due to concurrent request conflicts. Furthermore, this processing method prevents the second client from receiving the first response information during the effective period of the first timer, thereby avoiding diagnostic anomalies or even diagnostic failures on the second client.

[0022] In conjunction with the first aspect, in some implementations of the first aspect, the second request information includes a third diagnostic service identifier, and the method further includes: sending the second request information to the target device; receiving second response information sent by the target device, the second response information being a response to the second request information, the second response information being used to instruct the target device to perform the second diagnostic service, the second response information including a fourth diagnostic service identifier; and, if the third diagnostic identifier and the fourth diagnostic identifier are consistent, sending the second response information to the second client.

[0023] In this embodiment, if the third diagnostic service identifier and the fourth diagnostic service identifier are identical, the first module can send a second response message to the second client. This ensures that only legitimate and matching requests and responses are forwarded, thereby guaranteeing the reliability of the diagnostic results.

[0024] In conjunction with the first aspect, in some implementations of the first aspect, the second response information includes a second source address, and the step of sending the second response information to the second client when the third diagnostic service identifier and the fourth diagnostic service identifier are consistent includes: sending the second response information to the second client when the third diagnostic service identifier and the fourth diagnostic service identifier are consistent and the second source address is in an active state.

[0025] In this embodiment, since the second source address being active indicates that the second client has preempted the request, the first module forwards the second response information only when the second source address is active. This ensures the correctness and reliability of communication and avoids mistransmission of information or system abnormalities caused by address conflicts or inactive states.

[0026] In conjunction with the first aspect, in some implementations of the first aspect, before receiving the first response information sent by the target device, the method further includes: receiving route activation request information sent by the second client, the route activation request information being used to request the establishment of the first diagnostic channel; releasing the second diagnostic channel and establishing the first diagnostic channel according to the route activation request information; and starting a second timer according to the activation route request information, the first diagnostic channel being a diagnostic channel established between the first module and the first client; ignoring the first response information includes: ignoring the first response information if the second timer has not expired.

[0027] In this embodiment, if the second timer has not expired, the first module can ignore the first response information for the first client. This prevents the second client from receiving the first response information after preemption during the timer's validity period, thereby avoiding diagnostic anomalies or even diagnostic failures on the second client.

[0028] In conjunction with the first aspect, in some implementations of the first aspect, the method further includes: sending a route activation response message to the second client when the second timer times out, the route activation response message being used to indicate that the first diagnostic channel has been established.

[0029] In conjunction with the first aspect, in some implementations of the first aspect, the first diagnostic service is an over-the-air (OTA) technology asset acquisition service, and the second diagnostic service is a mass production vehicle evaluation and testing service; or, the first diagnostic service is a traceability code query service, and the second diagnostic service is an OTA technology upgrade service.

[0030] Secondly, a diagnostic device is provided, comprising a transceiver unit and a processing unit; the transceiver unit is configured to: receive a first request message sent by a first client, the first request message being used to request a target device to perform a first diagnostic service; send the first request message to the target device; and receive a first response message sent by the target device, the first response message being a response to the first request message; the processing unit is configured to ignore the first response message when a second client establishes a first diagnostic channel with a first module.

[0031] In conjunction with the second aspect, in some implementations of the second aspect, the first response information includes a first source address; the processing unit is specifically used to ignore the first response information when the first source address is in an inactive state.

[0032] In conjunction with the second aspect, in some implementations of the second aspect, the first request information includes a first diagnostic service identifier, and the first response message further includes a second diagnostic service identifier; the processing unit is further configured to determine that the first diagnostic service identifier and the second diagnostic service identifier are consistent.

[0033] In conjunction with the second aspect, in some implementations of the second aspect, the first request information includes the first source address, and the transceiver unit is further configured to receive second request information sent by the second client, the second request information being used to request the target device to perform a second diagnostic service, the second request information including the second source address; the processing unit is further configured to determine, based on the first source address, the second source address, and a first correspondence, that the priority of the second client is higher than the priority of the first client, the first correspondence being a correspondence between source address and client priority.

[0034] In conjunction with the second aspect, in some implementations of the second aspect, the processing unit is further configured to: start a first timer according to the second request information and send a waiting response information to the second client; and ignore the first response information if the first timer has not expired.

[0035] In conjunction with the second aspect, in some implementations of the second aspect, the second request information includes a third diagnostic service identifier; the transceiver unit is further configured to: send the second request information to the target device, receive a second response information sent by the target device, the second response information being a response to the second request information, the second response information including a fourth diagnostic service identifier; and, if the third diagnostic identifier and the fourth diagnostic identifier are consistent, send the second response information to the second client.

[0036] In conjunction with the second aspect, in some implementations of the second aspect, the second response information includes a second source address; the processing unit is further configured to send the second response information to the second client when the third diagnostic service identifier and the fourth diagnostic service identifier are consistent and the second source address is in an active state.

[0037] In conjunction with the second aspect, in some implementations of the second aspect, the transceiver unit is further configured to receive route activation request information sent by the second client, the route activation request information being used to request the establishment of the first diagnostic channel; the processing unit is further configured to release the second diagnostic channel and establish the first diagnostic channel according to the route activation request information, and to start a second timer according to the activation route request information, the first diagnostic channel being the diagnostic channel established between the first module and the first client; specifically, the processing unit is configured to ignore the first response information if the second timer has not expired.

[0038] In conjunction with the second aspect, in some implementations of the second aspect, the transceiver unit is further configured to send a route activation response message to the second client when the second timer times out, the route activation response message being used to indicate that the first diagnostic channel has been established.

[0039] In conjunction with the second aspect, in some implementations of the second aspect, the first diagnostic service is an over-the-air (OTA) technology asset acquisition service, and the second diagnostic service is a mass production vehicle evaluation and testing service; or, the first diagnostic service is a traceability code query service, and the second diagnostic service is an OTA technology upgrade service.

[0040] Thirdly, a diagnostic device is provided, comprising: at least one processor and a memory, wherein the at least one processor is coupled to the memory for reading and executing instructions in the memory, such that the device implements the method in any of the implementations of the first aspect described above.

[0041] Fourthly, a computer-readable storage medium is provided, the computer-readable storage medium storing program code, which, when run on a computer, causes the computer to perform the method in any of the implementations of the first aspect described above.

[0042] Fifthly, a chip is provided, the chip including circuitry for performing the method in any of the implementations of the first aspect described above.

[0043] Sixthly, a computer program product is provided, the computer product including a computer program that, when the computer program is run, causes a computer to perform the method in any of the implementations of the first aspect described above.

[0044] In a seventh aspect, a vehicle is provided, comprising: a diagnostic device according to any one of the implementations of the second and third aspects described above. Attached Figure Description

[0045] Figure 1 is a functional schematic diagram of a vehicle provided in an embodiment of this application;

[0046] Figure 2 is an example of a high-priority client failing to diagnose after triggering diagnostic preemption, as provided in an embodiment of this application.

[0047] Figure 3 is another example of a high-priority client failing to diagnose after triggering diagnostic preemption, as provided in the embodiments of this application.

[0048] Figure 4 shows the system architecture to which the diagnostic method provided in the embodiments of this application is applicable;

[0049] Figure 5 is a schematic flowchart of a diagnostic method provided in an embodiment of this application;

[0050] Figure 6 is a schematic flowchart of another diagnostic method provided in an embodiment of this application;

[0051] Figure 7 is a schematic flowchart of another diagnostic method provided in an embodiment of this application;

[0052] Figure 8 is a schematic flowchart of another diagnostic method provided in an embodiment of this application;

[0053] Figure 9 is a schematic flowchart of another diagnostic method provided in an embodiment of this application;

[0054] Figure 10 is a schematic diagram of a diagnostic device provided in an embodiment of this application;

[0055] Figure 11 is a schematic diagram of another diagnostic device provided in an embodiment of this application. Detailed Implementation

[0056] In the description of the embodiments of this application, unless otherwise stated, " / " means "or", for example, A / B can mean A or B; "and / or" in this document is merely a description of the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A existing alone, A and B existing simultaneously, and B existing alone. In this application, "at least one" means one or more, and "more" means two or more. "At least one of the following" or similar expressions refer to any combination of these items, including any combination of single or multiple items. For example, at least one of a, b, or c can represent: a, b, c, ab, ac, bc, or abc, where a, b, and c can be single or multiple.

[0057] The use of prefixes such as "first" and "second" in this application embodiment is solely for distinguishing different descriptive objects and does not limit the position, order, priority, quantity, or content of the described objects. The use of ordinal numbers and other prefixes to distinguish descriptive objects in this application embodiment does not constitute a limitation on the described objects. The description of the described objects is found in the claims or the context of the embodiments, and the use of such prefixes should not constitute unnecessary restrictions.

[0058] The technical solutions in the embodiments of this application will now be described with reference to the accompanying drawings.

[0059] Figure 1 is a functional schematic diagram of a vehicle 100 provided in an embodiment of this application.

[0060] The vehicle 100 involved in this application may include multiple subsystems, such as a perception system 120, a computing platform 130, and a diagnostic system 140. Optionally, the vehicle 100 may include more or fewer subsystems, and each subsystem may include one or more components. In addition, each subsystem and component of the vehicle 100 may be interconnected via wired or wireless means.

[0061] The perception system 120 may include several types of sensors for sensing information about the environment surrounding the vehicle 100. For example, the perception system 120 may include a positioning system, which may be a global positioning system (GPS), a BeiDou system, or another positioning system. The perception system 120 may include one or more of the following: an inertial measurement unit (IMU), lidar, millimeter-wave radar, ultrasonic radar, and a camera device.

[0062] Some or all of the functions of vehicle 100 can be controlled by computing platform 130. Computing platform 130 may include processors 131 to 13n (n being a positive integer). A processor is a circuit with signal processing capabilities. In one implementation, the processor can be a circuit with instruction read and execute capabilities, such as a central processing unit (CPU), microprocessor, graphics processing unit (GPU) (which can be understood as a type of microprocessor), or digital signal processor (DSP). In another implementation, the processor can implement certain functions through the logical relationships of hardware circuits. These logical relationships are fixed or reconfigurable. For example, the processor may be a hardware circuit implemented using an application-specific integrated circuit (ASIC) or a programmable logic device (PLD), such as an FPGA. In reconfigurable hardware circuits, the process of the processor loading a configuration document and configuring the hardware circuit can be understood as the process of the processor loading instructions to implement some or all of the functions of the aforementioned units. Furthermore, the processor can also be a hardware circuit designed for artificial intelligence, which can be understood as an ASIC, such as a neural network processing unit (NPU), tensor processing unit (TPU), deep learning processing unit (DPU), etc. In addition, the computing platform 130 may also include a memory for storing instructions. Some or all of the processors 131 to 13n can call the instructions in the memory to implement the corresponding functions.

[0063] The computing platform 130 can control the functions of the vehicle 100 based on inputs received from various subsystems (e.g., the sensing system 120). In some embodiments, the computing platform 130 can be used to provide control over many aspects of the vehicle 100 and its subsystems.

[0064] The diagnostic system 140 is responsible for monitoring, detecting, reporting, and repairing faults or anomalies in various vehicle systems.

[0065] Optionally, the above components are just an example. In actual applications, the components in each of the above modules may be added or deleted as needed.

[0066] The vehicle 100 in this application may include: road vehicles, water vehicles, air vehicles, industrial equipment, agricultural equipment, or entertainment equipment, etc. For example, vehicle 100 may be a means of transportation (such as commercial vehicles, passenger cars, motorcycles, flying cars, trains, etc.), industrial vehicles (such as forklifts, trailers, tractors, etc.), engineering vehicles (such as excavators, bulldozers, cranes, etc.), agricultural equipment (such as lawnmowers, harvesters, etc.), amusement equipment, toy vehicles, etc. The embodiments of this application do not specifically limit the type of vehicle.

[0067] The following uses vehicle 100 as an example of an intelligent vehicle to illustrate the technical problems that this application needs to solve and the technical solutions adopted.

[0068] As smart cars become increasingly common in daily life, users expect them to provide a more comfortable and intelligent experience. Against this backdrop, electronic control technology has gradually penetrated into various vehicle components, significantly improving vehicle performance and comfort. However, with increasingly complex vehicle structures and rising levels of automation, the electronic control systems of the entire vehicle are also becoming more complex, leading to a rise in after-sales diagnostic problems and increasing diagnostic difficulty.

[0069] When multiple diagnostic clients (e.g., remote diagnostics, OTA upgrades, local diagnostics, and device management) use the diagnostic channel simultaneously, a scenario will occur where the CAN ECU is being diagnosed at the same time. In this case, the vehicle needs to introduce a diagnostic preemption mechanism, that is, a higher-priority diagnostic client can preempt the diagnostic channel of a lower-priority diagnostic client to ensure that only one diagnostic client uses the diagnostic channel at any given time.

[0070] However, after a diagnostic preemption occurs, if the preempted low-priority client has already sent a diagnostic request to the CAN ECU but has not yet received a diagnostic response from the CAN ECU, the high-priority diagnostic client will receive the diagnostic response from the CAN ECU, causing the high-priority client to experience diagnostic anomalies or even diagnostic failures.

[0071] For example, as shown in Figure 2, according to relevant laws and regulations, vehicles need to undergo production vehicle evaluation (PVE) testing before leaving the factory. During PVE testing, the CAN diagnostic tool connects to the on-board diagnostics (OBD) standard interface to perform OBD diagnostic testing on the vehicle (this test is based on the OBD diagnostic protocol, not the unified diagnostic services (UDS) protocol). When the OTA asset acquisition module concurrently performs diagnostic services, it may cause PVE testing to fail. Specifically, before PVE testing, if the diagnostic services issued by the OTA asset acquisition module occupy the diagnostic channel, and the CAN diagnostic tool connects to the vehicle (without triggering the service but occupying the diagnostic channel), it will receive abnormal unexpected messages (i.e., asset acquisition response messages), causing PVE testing to fail. In addition, if diagnostic services issued by the OTA asset acquisition module are inserted in the middle of the PVE test, the CAN diagnostic tool will receive abnormal unexpected messages (asset acquisition response messages), causing PVE testing to fail.

[0072] For example, as shown in Figure 3, OTA upgrades rely on the UDS diagnostic service to send diagnostic commands to the corresponding ECU, thereby controlling the upgrade process. However, if a precise traceability code query process for device management exists before the OTA upgrade is triggered, it may cause the OTA upgrade to fail. Specifically, before the OTA upgrade is triggered, the device management module has already sent a precise traceability code query request to the corresponding ECU. Since the priority of the OTA upgrade service is higher than that of the device management service, the OTA upgrade service will trigger a preemption mechanism, which will cause the OTA upgrade module to receive the precise traceability code query response, resulting in the OTA upgrade failure.

[0073] To address the aforementioned issues, this application provides a diagnostic method, apparatus, and vehicle that can prevent high-priority diagnostic clients from receiving diagnostic responses for preempted low-priority clients, thereby avoiding diagnostic anomalies or even diagnostic failures for high-priority clients.

[0074] Figure 4 shows the system architecture to which the diagnostic method provided in the embodiments of this application is applicable.

[0075] As shown in Figure 4, this system architecture provides a vehicle operating system (VOS) diagnostic protocol stack, which can be located in the vehicle's microcontroller unit (MCU). The VOS diagnostic protocol stack includes: software component (SWC), runtime environment (RTE), diagnostic communication manager (DCM), protocol data unit router (PDU Router, PDUR), CAN transport protocol (CANTP), diagnostic over IP (DOIP), and seamless latency preemption processing module (diagnostic router manager, DRM).

[0076] Among them, SWC is a module that encapsulates some or all of the automotive electronic functions, including the specific implementation logic and related descriptive information. SWC can also communicate with CAN receiver diagnostic tools and / or Ethernet diagnostic tools; RTE provides a communication mechanism between components to ensure data transmission between different software components; DCM is used to implement fault detection and diagnostic functions; PDUR is responsible for the routing and forwarding of protocol data units (PDUs) and connects different transmission protocols; CANTP is used to process data transmission on the CAN bus and supports data segmentation and reassembly; DOIP provides IP-based diagnostic services and supports network communication and remote diagnostic functions.

[0077] DRM can achieve the following four sub-functions:

[0078] (1) Seamless delay processing: When a low-priority diagnostic client occupies the diagnostic channel, a high-priority client of a newly connected vehicle can send a route activation request to the DRM. After receiving the route activation request message, the DRM can cache it and start a timer. After the timer expires, the DRM sends a route activation response to the high-priority diagnostic client.

[0079] (2) Seamless preemption management: DRM can configure the priority of diagnostic clients based on diagnostic services, and support high-priority clients to preempt the diagnostic channels of low-priority clients; for diagnostic clients of the same priority, DRM will process the diagnostic request received first, and for the diagnostic request received later, DRM can reply with a negative response code (NRC) to the corresponding client, through which the reason for rejecting the diagnostic request can be explained.

[0080] (3) Replying to the waiting response information (e.g., 0x78 information): When the DRM forwards the diagnostic request sent by the low-priority client to the target device, but has not yet received the diagnostic response, the newly connected high-priority client preempts the diagnostic channel of the low-priority client and sends a new diagnostic request to the DRM. After receiving the new diagnostic request, the DRM can cache the new diagnostic request and reply to the high-priority client with 0x78 information on its behalf.

[0081] (4) Accurate diagnostic response reply: When DRM receives a diagnostic request, it records the source address (SA) and diagnostic service identifier (SID) of the diagnostic request. When DRM receives diagnostic response information, it forwards the diagnostic response information after determining that the SID and SA in the diagnostic response information are consistent with the SID and SA in the diagnostic request.

[0082] Figure 5 is a schematic flowchart of a diagnostic method provided in an embodiment of this application. Method 500 may include steps S501 to S504.

[0083] S501, the first client sends the first request information to the first module.

[0084] The first request information is used to request the target device to perform the first diagnostic service.

[0085] Optionally, the first module can be an MCU, DRM, MPU, or a non-sensory delay diagnostic module.

[0086] Optionally, the first client can be one of remote diagnostics, OTA upgrades, local diagnostics, and device management.

[0087] S502, the first module sends the first request information to the target device.

[0088] Optionally, the target device can be a component that communicates based on the CAN bus or Ethernet communication protocol; that is, the target device can be a CAN component or an Ethernet component.

[0089] S503, the target device sends the first response information to the first module.

[0090] The first response information is the response to the first request information.

[0091] In one possible implementation, the first request information includes a first source address. Before step S503, method 500 further includes: a first module receiving second request information sent by a second client, the second request information being used to request the target device to perform a second diagnostic service, the second request information including a second source address; then the first module can determine that the priority of the second client is higher than the priority of the first client based on the first source address, the second source address, and the first correspondence. In this way, determining the client priority based on the source address helps optimize the allocation of computing resources and ensures that critical diagnostic tasks are processed with priority.

[0092] The first correspondence can be pre-stored in the first module, and this first correspondence is the correspondence between the source address and the client priority.

[0093] For example, the first correspondence can be shown in Table 1 below.

[0094] Table 1

[0095] Optionally, before step S503, the first module can start a first timer based on the second request information and send a waiting response message to the second client. This effectively prevents the target device from receiving both the first and second request information simultaneously, thus preventing diagnostic failures due to concurrent request conflicts.

[0096] Optionally, the second client can be one of remote diagnostics, OTA upgrades, local diagnostics, and device management, and the second client and the first client belong to different client types.

[0097] Optionally, the first diagnostic service is over-the-air (OTA) technology asset acquisition service, and the second diagnostic service is mass production vehicle evaluation and testing service; or, the first diagnostic service is traceability code query service, and the second diagnostic service is OTA technology upgrade service.

[0098] S504, when the second client establishes a first diagnostic channel with the first module, the first module ignores the first response information.

[0099] Optionally, the establishment of the first diagnostic channel between the second client and the first module can be understood as the second client preempting the second diagnostic channel between the first client and the first module, that is, the second diagnostic channel is released and the first diagnostic channel is established.

[0100] Alternatively, the relationship between diagnostic services and diagnostic channels can be understood as follows: diagnostic services transmit and communicate data through diagnostic channels, that is, diagnostic channels are the transmission path or medium through which diagnostic services are realized.

[0101] Optionally, the first module ignoring the first response information can be understood as: the first module stops sending the first response information, or the first module discards the first response information.

[0102] In one possible implementation, the first request information includes a first diagnostic service identifier, and the first response message includes a second diagnostic service identifier. Before step S504, method 500 further includes: a first module determining that the first diagnostic service identifier and the second diagnostic service identifier do not match. In this way, the first module can correctly match the first request information and the first response information, thereby avoiding information confusion and conflict, and further preventing the second client from receiving the first response information after preemption.

[0103] In one possible implementation, if the first response information includes a first source address, then step S504 includes: ignoring the first response information if the first source address is in an inactive state.

[0104] In one possible implementation, the first request information includes a first diagnostic service identifier, and the first response information also includes a second diagnostic service identifier. Before the first module ignores the first response information, method 500 further includes: the first module determining that the first diagnostic service identifier and the second diagnostic service identifier are consistent. This approach helps improve the accuracy, security, and operational efficiency of information transmission, avoids information confusion and conflict, and further prevents the first client from receiving the first response information after a preemption occurs.

[0105] In one possible implementation, the consistency of the first diagnostic service identifier and the second diagnostic service identifier can be understood as: the first diagnostic service identifier and the second diagnostic service identifier are completely identical.

[0106] In one possible implementation, when the first module forwards the second request information to the target device, and the second request information includes a third diagnostic identifier, then after step S504, method 500 further includes: the first module receiving second response information sent by the target device, the second response information being a response to the second request information, and the second response information including a fourth diagnostic identifier; then the first module can send the second response information to the second client if the third diagnostic identifier and the fourth diagnostic identifier are consistent. This ensures that only valid and matching requests and responses are forwarded, avoiding the situation where the second response message is forwarded to the wrong client in a multi-client scenario, thereby guaranteeing the reliability of the diagnostic results.

[0107] Optionally, the second response information includes a second source address. If the third and fourth diagnostic service identifiers match, the second response information is sent to the second client. This includes sending the second response information to the second client if the third and fourth diagnostic service identifiers match and the second source address is active. Thus, since the second source address being active indicates that the second client has preempted the request, the first module only forwards the second response information when the second source address is active, ensuring the correctness and reliability of communication and avoiding mistransmission of information or system anomalies due to address conflicts or inactivity.

[0108] In one possible implementation, before step S503, the first module receives a route activation request from the second client, which requests the establishment of a first diagnostic channel. The first module can release the second diagnostic channel and establish the first diagnostic channel based on the route activation request, and start a second timer based on the activation request. The first diagnostic channel is the diagnostic channel established between the first module and the first client. In step S504, the first module can ignore the first response information if the second timer has not expired. After the second timer expires, the first module can send a route activation response to the second client, indicating that the second diagnostic channel has been established. This prevents the second client from receiving the first response information after preemption during the timer's validity period, thus avoiding diagnostic anomalies or even diagnostic failures on the second client.

[0109] In this embodiment, when the second client establishes a first diagnostic channel with the first module, the first module can ignore the first response information for the first client. This prevents the second client from receiving the first response information after preemption, thus avoiding diagnostic anomalies or even diagnostic failures on the second client.

[0110] Figure 6 is a schematic flowchart of another diagnostic method provided in the embodiment of this application. Method 600 can be a specific description of the implementation of configuring the second timer in the first module of method 500. Method 600 can include steps S601 to S608.

[0111] S601, Diagnostic Client 2 sends the first route activation request information to DRM.

[0112] The first route activation request information is used to request the DRM to establish a second diagnostic channel between the diagnostic client 2 and the DRM. The diagnostic client 2 can be the first client in method 500, and the DRM can be the first module in method 500.

[0113] S602, DRM sends the first route activation response information to diagnostic client 2.

[0114] The first route activation response information is used to indicate that a second diagnostic channel has been established between diagnostic client 2 and DRM.

[0115] S603, Diagnostic Client 2 sends the first request information to DRM.

[0116] The first request information is used to request the target device to perform the first diagnostic service.

[0117] Optionally, before step S603, the diagnostic client 2 may send multiple diagnostic request messages to the DRM, and correspondingly, the DRM may send response messages to the diagnostic client 2 for the multiple diagnostic requests.

[0118] S604, DRM sends the first request information to the target device.

[0119] Optionally, the target device may include a CAN component or an Ethernet component.

[0120] S605, Diagnostic Client 1 sends a second route activation request to DRM.

[0121] The second route activation request information is used to request the DRM to establish a first diagnostic channel between diagnostic client 1 and the DRM. The priority of diagnostic client 1 is higher than that of diagnostic client 2. Diagnostic client 1 can be the second client in method 500, and the second route activation request information can be the route activation request information in method 500.

[0122] Optionally, both the first client and the second client can be an Ethernet diagnostic tool.

[0123] S606, DRM receives the first response information sent by the target device.

[0124] The first response information can be a response to the first request information.

[0125] S607, DRM discards the first response information during the second timer's validity period.

[0126] Specifically, in step S605, after receiving the second routing diagnostic request information, the DRM can cache it, release the second diagnostic channel, and establish the first diagnostic channel (i.e., diagnostic client 1 preempts the diagnostic channel of diagnostic client 2). Simultaneously, the DRM can start a second timer. If the DRM receives the first response information during the validity period of the second timer, it can discard the first response information; that is, the DRM will not send the first response information to diagnostic client 1 or diagnostic client 2 during the validity period of the second timer.

[0127] Optionally, the effective period of the second timer can be set to 1.5 to 2 seconds.

[0128] S608, after the second timer expires, DRM sends a second route activation response message to diagnostic client 1.

[0129] The second route activation response information is used to indicate that a second diagnostic channel has been established between diagnostic client 1 and DRM.

[0130] In this embodiment of the application, during the effective period of the second timer, the DRM can discard the first response information, thereby preventing the diagnostic client 1 from receiving the first response information after a preemption, thus avoiding the phenomenon of diagnostic client 1 experiencing diagnostic anomalies or even diagnostic failures.

[0131] Figure 7 is a schematic flowchart of another diagnostic method provided in an embodiment of this application. Method 700 may include steps S701 to S705.

[0132] S701, Diagnostic Client 2 sends the first request information to DRM.

[0133] The first request information is used to request the target device to perform a first diagnostic service.

[0134] S702, DRM sends the first response information to diagnostic client 2.

[0135] The first response information may be a response to the first request information.

[0136] Specifically, DRM can send a first request message to the target device (not shown in Figure 7) and receive a first response message from the target device.

[0137] S703, Diagnostic Client 1 sends a second request message to DRM.

[0138] The second request information is used to request the target device to perform a second diagnostic service.

[0139] If the DRM determines that the priority of diagnostic client 1 is higher than that of diagnostic client 2, it can proceed to steps S704a to S705a; otherwise, it can proceed to steps S704b to S705b.

[0140] Optionally, the source address can be carried in the first request information and the second request information. Based on the source address and the pre-stored correspondence between the source address and the client priority (which can correspond to the first correspondence in method 500), DRM can determine the priority of diagnostic client 1 and diagnostic client 2.

[0141] S704a, DRM terminates the current diagnostic service of diagnostic client 2 and forwards the second request information to the target device.

[0142] S704b, DRM does not accept second request information.

[0143] S705a, DRM sends a second response message to diagnostic client 1.

[0144] Specifically, the DRM can receive a second response information from the target device and forward the second response information to the diagnostic client 1. This second response information is a response to the second request information.

[0145] S705b, DRM sends NRC to diagnostic client 1.

[0146] The NRC is configurable, meaning that the reason for rejecting the second request information can be explained in the NRC.

[0147] In this embodiment, the DRM supports high-priority clients preempting diagnostic channels from low-priority clients. Furthermore, after rejecting a diagnostic request, the DRM can send an NRC (Notification of Rejection) to the corresponding client, explaining the reason for the rejection. This approach improves resource utilization, efficiency, and reliability of the diagnostic system, ensures critical diagnostic tasks are prioritized, and allows clients to clearly understand why their diagnostic requests were not accepted, avoiding resource conflicts and duplicate requests, thereby optimizing the entire diagnostic process.

[0148] Figure 8 is a schematic flowchart of another diagnostic method provided in an embodiment of this application. Method 800 can be a specific description of the scenario in method 500 where the first module sends a waiting response information to the second client. Method 800 can include steps S801 to S808.

[0149] S801, Diagnostic Client 2 sends the first request information to DRM.

[0150] The first request information is used to request the target device to perform a first diagnostic service.

[0151] S802, DRM sends the first request information to the target device.

[0152] The target device may include a CAN component or an Ethernet component.

[0153] S803, Diagnostic Client 1 sends a second request message to DRM.

[0154] The second request information is used to request the target device to perform a second diagnostic service; the priority of diagnostic client 1 is lower than that of diagnostic client 2. Diagnostic client 1 can be the second client in method 500, and diagnostic client 2 can be the first client in method 500.

[0155] S804, if the diagnostic client 1 preempts the diagnostic client 2 and the DRM does not receive the first response information from the target device, the DRM starts the first timer and caches the second request information.

[0156] In this context, "diagnostic client 1 preempting diagnostic client 2" can be understood as: the second diagnostic channel between DRM and diagnostic client 2 is released, and the first diagnostic channel between DRM and diagnostic client 1 is established.

[0157] After step S804, if the first timer has not expired, method 800 may sequentially perform steps S805a, S806a, S807 and S808; if the first timer has expired, method 800 may sequentially perform steps S805b and S806b.

[0158] S805a, DRM sends a wait-for-response message to diagnostic client 1.

[0159] For example, the wait response information could be a 0x78 message.

[0160] S805b determines that the first timer has timed out and the DRM has not received the first response information.

[0161] S806a, DRM receives the first response information sent by the target device.

[0162] The first response information is a response to the first request information.

[0163] S806b, DRM sends a second request message to the target device.

[0164] S807: If the first timer has not expired, the DRM discards the first response information.

[0165] For example, DRM discarding the first response information can be understood as DRM not sending the first response information to diagnostic client 1 and diagnostic client 2.

[0166] S808, DRM sends a second request message to the target device.

[0167] In this embodiment, when the DRM forwards the first request information to the target device but has not yet received the first response information, diagnostic client 1 preempts the diagnostic channel of diagnostic client 2 and sends a second request information to the DRM. After receiving the second request information, the DRM can cache the second request information and reply to diagnostic client 1 with a waiting response message. This effectively avoids the target device receiving the first and second request information simultaneously, thereby preventing diagnostic failures caused by concurrent request conflicts.

[0168] Figure 9 is a schematic flowchart of another diagnostic method provided in the embodiment of this application. Method 900 can be a specific description of steps S501 to S504 in method 500. Method 900 can include steps S901 to S911.

[0169] S901, Diagnostic Client 2 sends the first request information to DRM.

[0170] The first request information is used to request the target device to perform a first diagnostic service. The first request information includes SA1 and SID1. SA1 indicates that the diagnostic client 2 is in an active state. SA1 can be the first source address in method 500, SID1 can be the first diagnostic service identifier in method 500, and DRM can be the first module in method 500.

[0171] S902, record SA1 and SID1 from the first request information.

[0172] S903, DRM sends the first request information to the target device.

[0173] The target device may include a CAN component or an Ethernet component.

[0174] S904, Diagnostic Client 1 sends a second request message to DRM.

[0175] The second request information includes SA2 and SID2. SA2 can be the second source address in method 500, and SID2 can be the third diagnostic service identifier in method 500. The priority of diagnostic client 1 is higher than that of diagnostic client 2. Diagnostic client 1 can be the second client in method 500, and diagnostic client 2 can be the first client in method 500.

[0176] S905, if diagnostic client 1 preempts diagnostic client 2's diagnostic channel, DRM records SA2 and SID2 in the second request information.

[0177] In this context, "diagnostic client 1 preempting diagnostic client 2" can be understood as follows: the second diagnostic channel between DRM and diagnostic client 2 is released, and the first diagnostic channel between DRM and diagnostic client 1 is established. When diagnostic client 1 preempts the diagnostic channel of diagnostic client 2, DRM can set SA2 to an active state and SA1 to an inactive state.

[0178] S906, DRM sends a second request message to the target device.

[0179] S907, DRM receives the first response information sent by the target device.

[0180] The first response information is a response to the first request information, and the first response information includes SID3, which may be the second diagnostic service identifier in method 500.

[0181] S908, DRM determines that the stored SID1 is consistent with SID3 in the first response information, and the corresponding SA is in an inactive state, and discards the first response information.

[0182] Among them, the SA mentioned above can be the SA in the first response information, and the SA can be SA1.

[0183] S909, DRM receives the second response information sent by the target device.

[0184] The second response information is used to respond to the second request information. The second response information may include SID4, which may be the fourth diagnostic service identifier in method 500.

[0185] S910, DRM determines that the stored SID2 is consistent with SID4 in the second response information, and the corresponding SA is in an active state.

[0186] The corresponding SA can be the SA in the second response information, and this SA can be SA2.

[0187] S911, DRM sends a second response message to diagnostic client 2.

[0188] In this embodiment, after receiving diagnostic request information (including first request information and second request information) sent by the diagnostic client, the DRM can record the SA and SID of the diagnostic request information. When a diagnostic client preempts the request, and the SA and TA in the diagnostic response information received by the DRM are consistent with the SA and SID in the corresponding diagnostic request information, the DRM forwards the diagnostic response information to the corresponding diagnostic client. In this way, it is ensured that only legitimate and matching requests and responses are forwarded, avoiding the situation where the response message is forwarded to the wrong client in a multi-client scenario, thereby ensuring the reliability of the diagnostic results.

[0189] It should be understood that, in the various embodiments of this application, unless otherwise specified or in case of logical conflict, the terms and / or descriptions between the various embodiments are consistent and can be referenced by each other, and the technical features in different embodiments can be combined to form new embodiments according to their inherent logical relationships.

[0190] Figure 10 is a schematic diagram of a diagnostic device provided in an embodiment of this application. The device 1000 may include a transceiver unit 1010, a storage unit 1020, and a processing unit 1030. The transceiver unit 1010 is used to send and receive instructions and / or data; the storage unit 1020 is used to implement corresponding storage functions and store corresponding instructions and / or data; the processing unit 1030 is used to perform data processing so that the device 1000 can implement the aforementioned diagnostic method.

[0191] In one embodiment, the diagnostic device 1000 includes a transceiver unit 1010 and a processing unit 1030. The transceiver unit 1010 is configured to: receive a first request message sent by a first client, the first request message being used to request a target device to perform a first diagnostic service; send the first request message to the target device; and receive a first response message sent by the target device, the first response message being a response to the first request message. The processing unit 1030 is configured to ignore the first response message when a second client establishes a first diagnostic channel with a first module.

[0192] In one possible implementation, the first response information includes a first source address; the processing unit 1030 is specifically used to ignore the first response information when the first source address is in an inactive state.

[0193] In one possible implementation, the first request information includes a first diagnostic service identifier, and the first response message also includes a second diagnostic service identifier; the processing unit 1030 is further configured to determine that the first diagnostic service identifier and the second diagnostic service identifier are consistent.

[0194] In one possible implementation, the first request information is the first source address. The transceiver unit 1010 is further configured to receive a second request information sent by a second client. The second request information is used to request the target device to perform a second diagnostic service. The second request information includes a second source address. The processing unit 1030 is further configured to determine that the priority of the second client is higher than the priority of the first client based on the first source address, the second source address, and a first correspondence relationship. The first correspondence relationship is the correspondence between the source address and the client priority.

[0195] In one possible implementation, the processing unit 1030 is configured to: start a first timer based on the second request information and send a waiting response information to the second client; and ignore the first response information if the first timer has not expired.

[0196] In one possible implementation, the second request information includes a third diagnostic service identifier; the transceiver unit 1010 is further configured to: send the second request information to the target device, receive the second response information sent by the target device, the second response information being a response to the second request information, the second response information including a fourth diagnostic service identifier; and, if the third diagnostic identifier and the fourth diagnostic identifier are consistent, send the second response information to the second client.

[0197] In one possible implementation, the second response information includes a second source address; the processing unit 1030 is further configured to send the second response information to the second client when the third diagnostic service identifier and the fourth diagnostic service identifier are consistent and the second source address is in an active state.

[0198] In one possible implementation, the transceiver unit 1010 is further configured to receive route activation request information sent by the second client, the route activation request information being used to request the establishment of a first diagnostic channel; the processing unit 1030 is further configured to release the second diagnostic channel and establish the first diagnostic channel according to the route activation request information, and to start a second timer according to the route activation request information; the processing unit 1030 is specifically configured to ignore the first response information if the second timer has not expired.

[0199] In one possible implementation, the transceiver unit 1010 is further configured to send a route activation response message to the second client when the second timer times out. The route activation response message is used to indicate that the first diagnostic channel has been established.

[0200] In one possible implementation, the first diagnostic service is an over-the-air (OTA) technology asset acquisition service, and the second diagnostic service is a mass production vehicle evaluation and testing service; alternatively, the first diagnostic service is a traceability code query service, and the second diagnostic service is an OTA technology upgrade service.

[0201] Figure 11 is a schematic diagram of another diagnostic device provided in an embodiment of this application.

[0202] The device 1100 includes a memory 1110, a processor 1120, and a communication interface 1130. The memory 1110, processor 1120, and communication interface 1130 are connected via an internal connection path. The memory 1110 stores instructions, and the processor 1120 executes the instructions stored in the memory 1110 to control the communication interface 1130 to acquire information, enabling the device 1100 to implement the aforementioned diagnostic method. Optionally, the memory 1110 can be coupled to the processor 1120 via an interface, or it can be integrated with the processor 1120.

[0203] It should be noted that the communication interface 1130 described above uses a transceiver device, such as, but not limited to, a transceiver. The communication interface 1130 may also include an input / output interface.

[0204] The processor 1120 stores one or more computer programs, which include instructions. When the instructions are executed by the processor 1120, the device 1100 performs the diagnostic methods described in the above embodiments.

[0205] In implementation, each step of the above method can be completed by the integrated logic circuitry of the hardware in the processor 1120 or by instructions in software form. The method disclosed in the embodiments of this application can be directly implemented by a hardware processor, or by a combination of hardware and software modules in the processor. The software modules can reside in random access memory, flash memory, read-only memory, programmable read-only memory, electrically erasable programmable memory, registers, or other mature storage media in the art. This storage medium is located in memory 1110, and the processor 1120 reads the information in memory 1110 and, in conjunction with its hardware, completes the steps of the above method. To avoid repetition, detailed descriptions are not provided here.

[0206] Optionally, the communication interface 1130 in FIG11 can implement the transceiver unit 1010 in FIG10, the memory 1110 in FIG11 can implement the storage unit 1020 in FIG10, and the processor 1120 in FIG11 can implement the processing unit 1030 in FIG10.

[0207] This application also provides a computer-readable storage medium storing program code that, when run on a computer, causes the computer to perform any of the methods shown in Figures 5 to 9.

[0208] This application also provides a computer program product, which includes a computer program that, when run, causes the computer to perform any of the methods shown in Figures 5 to 9.

[0209] This application also provides a chip, including: a circuit for performing any of the methods in Figures 5 to 9 above.

[0210] This application also provides a vehicle, including a diagnostic device as shown in FIG10 or FIG11.

[0211] Those skilled in the art will recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0212] Those skilled in the art will understand that, for the sake of convenience and brevity, the specific working processes of the systems, devices, and units described above can be referred to the corresponding processes in the foregoing method embodiments, and will not be repeated here.

[0213] In the several embodiments provided in this application, it should be understood that the disclosed systems, apparatuses, and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces; the indirect coupling or communication connection between apparatuses or units may be electrical, mechanical, or other forms.

[0214] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0215] In addition, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit.

[0216] If the aforementioned functions are implemented as software functional units 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 portion 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 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. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

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

Claims

1. A diagnostic method, characterized in that, The method includes: Receive a first request message sent by a first client, the first request message being used to request the target device to perform a first diagnostic service; Send the first request information to the target device; Receive first response information sent by the target device, wherein the first response information is a response to the first request information; If the second client establishes a first diagnostic channel with the first module, the first response information is ignored.

2. The method as described in claim 1, characterized in that, The first response information includes a first source address. When the second client establishes a first diagnostic channel with the first module, ignoring the first response information includes: If the first source address is inactive, ignore the first response information.

3. The method as described in claim 2, characterized in that, The first request information includes a first diagnostic service identifier, and the first response message further includes a second diagnostic service identifier. Before ignoring the first response information, the method further includes: It is determined that the first diagnostic service identifier and the second diagnostic service identifier are consistent.

4. The method as described in claim 3, characterized in that, The first request information includes the first source address. Before receiving the first response information sent by the target device, the method further includes: The system receives a second request message sent by the second client. The second request message is used to request the target device to perform a second diagnostic service. The second request message includes a second source address. Based on the first source address, the second source address, and the first correspondence, it is determined that the priority of the second client is higher than that of the first client. The first correspondence is the correspondence between the source address and the client priority.

5. The method as described in claim 4, characterized in that, Before receiving the first response information sent by the target device, the method further includes: The first timer is started according to the second request information, and a waiting response information is sent to the second client; Ignoring the first response information includes: If the first timer has not expired, ignore the first response information.

6. The method as described in claim 5, characterized in that, The second request information includes a third diagnostic service identifier, and the method further includes: Send the second request information to the target device; Receive a second response information sent by the target device, the second response information being a response to the second request information, the second response information including a fourth diagnostic service identifier; If the third diagnostic service identifier and the fourth diagnostic service identifier are consistent, the second response information is sent to the second client.

7. The method as described in claim 6, characterized in that, The second response information includes a second source address. The step of sending the second response information to the second client when the third diagnostic service identifier and the fourth diagnostic service identifier are consistent includes: If the third diagnostic service identifier and the fourth diagnostic service identifier are the same, and the second source address is active, the second response information is sent to the second client.

8. The method according to any one of claims 1 to 7, characterized in that, Before receiving the first response information sent by the target device, the method further includes: Receive route activation request information sent by the second client, the route activation request information being used to request the establishment of the first diagnostic channel; Based on the route activation request information, the second diagnostic channel is released and the first diagnostic channel is established, and the second timer is started based on the route activation request information. The first diagnostic channel is the diagnostic channel established between the first client and the first module. Ignoring the first response information includes: If the second timer does not expire, the first response information is ignored.

9. The method as described in claim 8, characterized in that, The method further includes: If the second timer times out, a route activation response message is sent to the second client, which indicates that the first diagnostic channel has been established.

10. The method according to any one of claims 1 to 9, characterized in that, The first diagnostic service is an over-the-air (OTA) technology asset acquisition service, and the second diagnostic service is a mass production vehicle evaluation and testing service; or, the first diagnostic service is a traceability code query service, and the second diagnostic service is an OTA technology upgrade service.

11. A diagnostic device, characterized in that, The device includes: a transceiver unit and a processing unit; The transceiver unit is used for: Receive a first request message sent by a first client, the first request message being used to request the target device to perform a first diagnostic service; Send the first request information to the target device; Receive first response information sent by the target device, wherein the first response information is a response to the first request information; The processing unit is configured to ignore the first response information when the second client establishes a first diagnostic channel with the first module.

12. The apparatus as claimed in claim 11, characterized in that, The first response information includes the first source address; The processing unit is specifically used to ignore the first response information when the first source address is in an inactive state.

13. The apparatus as claimed in claim 12, characterized in that, The first request information includes a first diagnostic service identifier, and the first response message also includes a second diagnostic service identifier; The processing unit is further configured to determine that the first diagnostic service identifier and the second diagnostic service identifier are consistent.

14. The apparatus as claimed in claim 13, characterized in that, The first request information includes the first source address; The transceiver unit is further configured to receive a second request information sent by the second client, the second request information being used to request the target device to perform a second diagnostic service, the second request information including a second source address; The processing unit is further configured to determine, based on the first source address, the second source address, and the first correspondence, that the priority of the second client is higher than the priority of the first client, wherein the first correspondence is the correspondence between the source address and the client priority.

15. The apparatus as claimed in claim 14, characterized in that, The processing unit is further configured to: The first timer is started according to the second request information, and a waiting response information is sent to the second client; If the first timer has not expired, ignore the first response information.

16. The apparatus as claimed in claim 13, characterized in that, The second request information includes a third diagnostic service identifier; The transceiver unit is further configured to: Send the second request information to the target device; Receive a second response information sent by the target device, the second response information being a response to the second request information, the second response information including a fourth diagnostic service identifier; If the third diagnostic service identifier and the fourth diagnostic service identifier are consistent, the second response information is sent to the second client.

17. The apparatus as claimed in claim 16, characterized in that, The second response information includes the second source address; The processing unit is further configured to send the second response information to the second client when the third diagnostic service identifier and the fourth diagnostic service identifier are consistent and the second source address is in an active state.

18. The apparatus as claimed in any one of claims 11 to 17, characterized in that, The transceiver unit is also configured to receive routing activation request information sent by the second client, the routing activation request information being used to request the establishment of the first diagnostic channel; The processing unit is further configured to release the second diagnostic channel and establish the first diagnostic channel according to the route activation request information, and to start a second timer according to the activation route request information, wherein the first diagnostic channel is a diagnostic channel established between the first module and the first client; The processing unit is specifically used to ignore the first response information if the second timer has not expired.

19. The apparatus as claimed in claim 18, characterized in that, The transceiver unit is further configured to send a route activation response message to the second client when the second timer times out, the route activation response message being used to indicate that the first diagnostic channel has been established.

20. The apparatus as claimed in any one of claims 11 to 19, characterized in that, The first diagnostic service is an over-the-air (OTA) technology asset acquisition service, and the second diagnostic service is a mass production vehicle evaluation and testing service; or, the first diagnostic service is a traceability code query service, and the second diagnostic service is an OTA technology upgrade service.

21. A diagnostic device, characterized in that, The device includes a processor and a memory, the processor being coupled to the memory, the memory being used to store computer programs or instructions, and the processor being used to execute the computer programs or instructions in the memory, such that the method of any one of claims 1 to 10 is performed.

22. A chip, characterized in that, The chip includes circuitry for performing the method as described in any one of claims 1 to 10.

23. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores program code that, when executed on a computer, causes the computer to perform the method as described in any one of claims 1 to 10.

24. A computer program product, characterized in that, The computer product includes a computer program that, when run by a processor, causes the method as described in any one of claims 1 to 10 to be performed.

25. A vehicle, characterized in that, The vehicle includes the device as described in any one of claims 11 to 21.

Images