WO2024124964A1 - 车辆诊断路由方法、装置、系统、车辆及存储介质 - Google Patents

车辆诊断路由方法、装置、系统、车辆及存储介质 Download PDF

Info

Publication number
WO2024124964A1
WO2024124964A1 PCT/CN2023/115500 CN2023115500W WO2024124964A1 WO 2024124964 A1 WO2024124964 A1 WO 2024124964A1 CN 2023115500 W CN2023115500 W CN 2023115500W WO 2024124964 A1 WO2024124964 A1 WO 2024124964A1
Authority
WO
WIPO (PCT)
Prior art keywords
node
diagnostic
client
request message
routing
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Ceased
Application number
PCT/CN2023/115500
Other languages
English (en)
French (fr)
Inventor
朱鹏波
谢燕艳
温小锋
邹金露
高德申
高斌
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Guangzhou Automobile Group Co Ltd
Original Assignee
Guangzhou Automobile Group Co Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Guangzhou Automobile Group Co Ltd filed Critical Guangzhou Automobile Group Co Ltd
Priority to EP23902172.8A priority Critical patent/EP4629602A4/en
Publication of WO2024124964A1 publication Critical patent/WO2024124964A1/zh
Anticipated expiration legal-status Critical
Ceased legal-status Critical Current

Links

Classifications

    • B—PERFORMING OPERATIONS; TRANSPORTING
    • B60—VEHICLES IN GENERAL
    • B60R—VEHICLES, VEHICLE FITTINGS, OR VEHICLE PARTS, NOT OTHERWISE PROVIDED FOR
    • B60R16/00—Electric or fluid circuits specially adapted for vehicles and not otherwise provided for; Arrangement of elements of electric or fluid circuits specially adapted for vehicles and not otherwise provided for
    • B60R16/02—Electric or fluid circuits specially adapted for vehicles and not otherwise provided for; Arrangement of elements of electric or fluid circuits specially adapted for vehicles and not otherwise provided for electric constitutive elements
    • B60R16/023—Electric or fluid circuits specially adapted for vehicles and not otherwise provided for; Arrangement of elements of electric or fluid circuits specially adapted for vehicles and not otherwise provided for electric constitutive elements for transmission of signals between vehicle parts or subsystems
    • G—PHYSICS
    • G07—CHECKING-DEVICES
    • G07C—TIME OR ATTENDANCE REGISTERS; REGISTERING OR INDICATING THE WORKING OF MACHINES; GENERATING RANDOM NUMBERS; VOTING OR LOTTERY APPARATUS; ARRANGEMENTS, SYSTEMS OR APPARATUS FOR CHECKING NOT PROVIDED FOR ELSEWHERE
    • G07C5/00—Registering or indicating the working of vehicles
    • G07C5/08—Registering or indicating performance data other than driving, working, idle, or waiting time, with or without registering driving, working, idle or waiting time
    • G07C5/0808—Diagnosing performance data
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/12—Protocols specially adapted for proprietary or special-purpose networking environments, e.g. medical networks, sensor networks, networks in vehicles or remote metering networks
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/50—Network services
    • H04L67/60—Scheduling or organising the servicing of application requests, e.g. requests for application data transmissions using the analysis and optimisation of the required network resources
    • H04L67/62—Establishing a time schedule for servicing the requests
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/50—Network services
    • H04L67/60—Scheduling or organising the servicing of application requests, e.g. requests for application data transmissions using the analysis and optimisation of the required network resources
    • H04L67/63—Routing a service request depending on the request content or context
    • G—PHYSICS
    • G07—CHECKING-DEVICES
    • G07C—TIME OR ATTENDANCE REGISTERS; REGISTERING OR INDICATING THE WORKING OF MACHINES; GENERATING RANDOM NUMBERS; VOTING OR LOTTERY APPARATUS; ARRANGEMENTS, SYSTEMS OR APPARATUS FOR CHECKING NOT PROVIDED FOR ELSEWHERE
    • G07C2205/00—Indexing scheme relating to group G07C5/00
    • G07C2205/02—Indexing scheme relating to group G07C5/00 using a vehicle scan tool
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
    • H04L12/40—Bus networks
    • H04L2012/40208—Bus networks characterized by the use of a particular bus standard
    • H04L2012/40215—Controller Area Network CAN
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
    • H04L12/40—Bus networks
    • H04L2012/40267—Bus for use in transportation systems
    • H04L2012/40273—Bus for use in transportation systems the transportation system being a vehicle
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L43/00—Arrangements for monitoring or testing data switching networks
    • H04L43/50—Testing arrangements

Definitions

  • Embodiments of the present application relate to the field of diagnostic communication technology, and in particular, to a vehicle diagnostic routing method, device, system, vehicle, and storage medium.
  • the diagnostic request message sent by the client passes through the client, the first node, the second node, the third node, and the diagnosed node in sequence, and is finally routed to the diagnosed node.
  • the diagnosed node After receiving the diagnostic request message, the diagnosed node sends a diagnostic response message, and the diagnostic response message passes through the diagnosed node, the third node, the second node, the first node, and the client in sequence, and is finally routed to the client.
  • the total routing time of the diagnostic request message and the diagnostic response message exceeds the expected time, which will cause the client to be unable to receive the diagnostic response message corresponding to the diagnostic request message within the expected time, causing the client response timeout, thereby causing the diagnostic communication failure.
  • the expected time refers to the time the client expects to receive a response after successfully sending a request, which is called P2client in this field.
  • Embodiments of the present application provide a vehicle diagnostic routing method, device, system, vehicle, and storage medium to improve the above-mentioned problems.
  • an embodiment of the present application provides a vehicle diagnostic routing method.
  • the method includes: upon receiving a diagnostic request message sent by a client, forwarding the diagnostic request message; if no diagnostic response is received from a next-level node within a first timing period, sending a message to the next-level node requesting the client to wait, so as to notify the client to wait until a preset condition is met.
  • an embodiment of the present application provides a vehicle diagnostic routing method.
  • the method includes: after a client sends a diagnostic request message, an intermediate node routes and forwards the diagnostic request message according to the method described in any one of claims 1 to 5, and the intermediate node is a node between the client and the diagnosed node; upon receiving the diagnostic request message, the diagnosed node determines that the routing of the diagnostic request message ends.
  • an embodiment of the present application provides a vehicle diagnostic routing device.
  • the device includes: a first reporting The first message forwarding module is used to forward the diagnostic request message when receiving the diagnostic request message sent by the client; the second message forwarding module is used to send a message to the upper-level node requesting the client to wait if no diagnostic response is received from the lower-level node within the first timing period, so as to notify the client to wait until the preset conditions are met.
  • an embodiment of the present application provides a vehicle diagnostic routing system.
  • the system includes: a client, which is used to send a diagnostic request message; an intermediate node, which is used to route and forward the diagnostic request message according to the method provided in the first aspect of the embodiment of the present application, and the intermediate node is a node between the client and the diagnosed node; the diagnosed node is used to determine that the routing of the diagnostic request message ends when receiving the diagnostic request message.
  • an embodiment of the present application provides a vehicle.
  • the vehicle includes a memory, one or more processors, and one or more applications.
  • the one or more applications are stored in the memory and are configured to cause the one or more processors to execute the method provided in the embodiment of the present application when called by the one or more processors.
  • an embodiment of the present application provides a computer-readable storage medium.
  • the computer-readable storage medium stores a program code, and the program code is configured to cause the processor to execute the method provided by the embodiment of the present application when called by the processor.
  • the embodiments of the present application provide a vehicle diagnostic routing method, device, system, vehicle and storage medium.
  • the method can automatically send a message requesting the client to wait if the node between the client and the diagnosed node does not receive a diagnostic response from the next-level node within a first timing period, and notify the client to wait. This can avoid diagnostic routing and response timeouts, avoid diagnostic communication failures, and thus improve the success rate of diagnostic communication.
  • FIG1 is a flow chart of a method for vehicle diagnostic routing according to an exemplary embodiment of the present application.
  • FIG2 is a schematic diagram of the structure of a vehicle diagnostic routing system provided by an embodiment of the present application.
  • FIG3 is a flow chart of a vehicle diagnostic routing method provided by an embodiment of the present application.
  • FIG4 is a flow chart of a vehicle diagnostic routing method provided by an embodiment of the present application.
  • FIG5 is a flow chart of a vehicle diagnostic routing method provided by an embodiment of the present application.
  • FIG6 is a schematic diagram of a diagnostic service identifier provided by an exemplary embodiment of the present application.
  • FIG7 is a flow chart of a vehicle diagnostic routing method provided by an exemplary embodiment of the present application.
  • FIG8 is a schematic diagram of the structure of a vehicle diagnostic routing device provided by an embodiment of the present application.
  • FIG9 is a schematic diagram of the structure of a vehicle diagnostic routing system provided by an embodiment of the present application.
  • FIG10 is a schematic structural diagram of a vehicle provided in an embodiment of the present application.
  • FIG. 11 is a schematic diagram of the structure of a computer-readable storage medium provided in an embodiment of the present application.
  • FIG2 is a schematic diagram of the structure of a vehicle diagnostic routing system provided in an embodiment of the present application.
  • the vehicle diagnostic routing system 100 can be applied to a vehicle to implement the vehicle diagnostic routing method provided in an embodiment of the present application.
  • the vehicle diagnostic routing system 100 may include a client 110, an intermediate node 120, and a diagnosed node 130.
  • the client 110 may initiate a diagnostic request message, and the diagnostic request message is routed and forwarded through the intermediate node 120 and finally routed to the diagnosed node 130.
  • the diagnosed node 130 executes the diagnostic operation requested by the client 110 according to the diagnostic request message, and after the diagnostic operation is completed, sends a diagnostic response message.
  • the diagnostic response message is routed and forwarded through the intermediate node 120 and finally routed to the client 110.
  • the client 110, the intermediate node 120, and the diagnosed node 130 in the embodiment of the present application may include but are not limited to various electronic control units (Electronic Control Unit, referred to as ECU), microcontroller units (Microcontroller Unit, referred to as MCU), vehicle control units (VCU), zone control units (ZCU), etc. on the vehicle.
  • ECU Electronic Control Unit
  • MCU microcontroller Unit
  • VCU vehicle control units
  • ZCU zone control units
  • the client 110 can also be an electronic device external to the vehicle, such as a diagnostic instrument or other tester.
  • the intermediate node in the embodiment of the present application may include one or more nodes.
  • the vehicle diagnostic routing method can be applied to an intermediate node 120 in a vehicle diagnostic routing system 100 or a vehicle diagnostic routing device 200 mentioned below or an intermediate node 320 or a vehicle 400 in a vehicle diagnostic routing system 300.
  • the vehicle diagnostic routing method can include the following steps S110 and S120.
  • Step S110 forwarding the diagnosis request message when receiving the diagnosis request message sent by the client.
  • the diagnostic request message in the embodiment of the present application refers to a message sent by the client to the diagnosed node to instruct the diagnosed node to perform a corresponding diagnostic operation.
  • the diagnostic request message may include the diagnostic identification (Identity document, referred to as Id) information of the diagnosed node, and the diagnostic identification information is used to uniquely identify each node.
  • the execution subject for example, the intermediate node in the embodiment of the present application locally stores a subnet routing identification table, and the subnet routing identification table may include the diagnosis identification information of the node itself and the diagnosis identification information of all subordinate nodes of the node.
  • the subordinate node refers to the node that the diagnosis request message needs to pass through or reach after the current node routing forwarding in the routing process from the client to the diagnosed node, and the subordinate node may include the diagnosed node.
  • the subordinate nodes of the current node include the second node, the third node and the diagnosed node
  • the subnet routing identification table of the first node may include the diagnosis identification information of the first node, the second node, the third node and the diagnosed node
  • the subnet routing identification table of the second node may include the diagnosis identification information of the second node, the third node and the diagnosed node
  • the subnet routing identification table of the third node may include the diagnosis identification information of the third node and the diagnosed node.
  • the diagnosed node can set whether it has a subnet routing identification table according to actual needs.
  • the diagnostic identification information of the next-level node can be searched in the subnet routing identification table according to the diagnostic identification information of the diagnosed node.
  • the diagnostic identification information forwards the diagnostic request message to the next level node, where the next level node may be an intermediate node or a diagnosed node.
  • Step S120 If no diagnostic response is received from the next-level node within the first timing period, a message requesting the client to wait is sent to the upper-level node to notify the client to wait until a preset condition is met.
  • the diagnostic response of the next-level node in the embodiment of the present application can be any response of the next-level node.
  • the response of the next-level node can be any diagnostic response of the diagnosed node, and the response of the next-level node can also be a message sent by the next-level node requesting the client to wait.
  • the message requesting the client to wait in the embodiment of the present application may include a target negative response code (Negative Response Code, referred to as NRC).
  • NRC target negative response code
  • the target NRC refers to the NRC of the request correctly received-response pending (Request Correctly Received-Response Pending, referred to as RCRRP) in the unified diagnostic service (Unified Diagnostic Services, referred to as UDS).
  • RCRRP Request Correctly Received-Response Pending
  • UDS Unified Diagnostic Services
  • the diagnosed node should send a positive response or a negative response, and the code of the positive response or the negative response should be different from the target NRC.
  • the negative response of the target NRC can be repeated by the diagnosed node until the diagnostic operation requested by the client is completed and the diagnostic response message sent by the diagnosed node is sent. It should be noted that, according to actual needs, other specific messages for requesting the client to wait but not including the target NRC can also be set.
  • a timer for example, a P2server timer
  • the diagnostic response identifier (Identity document, referred to as Id) of the diagnosed node may be used.
  • the diagnostic response identifier may be "0x785" to send a message to the upper-level node at a preset period requesting the client to wait.
  • the first timing duration in the embodiment of the present application may refer to the duration defined by the time parameter of the P2server timer.
  • the time parameters of the P2server timer include the P2server_max time parameter and the P2*server_max time parameter.
  • the duration defined by the P2server_max time parameter is 50 milliseconds
  • the duration defined by the P2*server_max time parameter is 5000 milliseconds.
  • the diagnosed node responds "50 03 00 32 01 F4", which means that the diagnosed node informs the client that it will send a response within the P2server_max time parameter, but when the diagnosed node is busy with other things and temporarily has no time to respond to the client's diagnostic request message, it will send a response within the P2*server_max parameter time.
  • the preset period in the embodiment of the present application refers to the time interval for sending the message that the client is requested to wait for.
  • the preset period can be set according to actual needs, for example, the preset period can be 2 seconds.
  • the preset condition in the embodiment of the present application refers to the condition that there is no need to continue to send the message requesting the client to wait, and when the preset condition is met, the message requesting the client to wait is no longer sent.
  • a diagnostic response from the diagnosed node is received, it is determined that the preset condition is met.
  • the second timing duration is greater than the first timing duration, and the second timing duration refers to the maximum timeout value (timeout), for example, the second timing duration is 60 seconds.
  • the above-mentioned diagnostic response of the diagnosed node may refer to any response of the diagnosed node, which may include a positive response or a negative response.
  • the node between the client and the diagnosed node can automatically send a message requesting the client to wait if no diagnostic response is received from the next-level node within a first timing period, and notify the client to wait, thereby avoiding diagnostic routing and response timeouts, avoiding diagnostic communication failures, and thus improving the success rate of diagnostic communication.
  • the vehicle diagnostic routing method can be applied to the vehicle diagnostic routing system 100 or the vehicle diagnostic routing device 200 or the vehicle diagnostic routing system 300 or the vehicle 400 mentioned below.
  • the vehicle diagnostic routing method can include the following steps S210 and S220.
  • Step S210 After the client sends a diagnosis request message, the intermediate node routes and forwards the diagnosis request message.
  • the intermediate node is a node between the client and the diagnosed node.
  • the intermediate node routes and forwards the diagnosis request message according to the vehicle diagnosis routing method shown in FIG. 3 .
  • the above steps S110 and S120 which will not be described in detail here.
  • the intermediate node in the embodiment of the present application may include one or more nodes.
  • Each of the one or more nodes may include a subnet routing identification table.
  • the subnet routing identification table of each node may include the diagnosis identification information of the node itself and the diagnosis identification information of all subordinate nodes.
  • the specific description of the subordinate nodes may refer to the relevant parts in the above-mentioned step S110.
  • the same communication protocol may be used between the client, one or more nodes, and two adjacent nodes among the diagnosed nodes.
  • different communication protocols can be used between the client, one or more nodes, and two adjacent nodes in the diagnosed node.
  • the diagnostic routing also involves protocol conversion, the diagnostic response time is relatively long, which can easily lead to a diagnostic response timeout and cause a diagnostic communication failure.
  • the intermediate node in the present application routes and forwards the diagnostic request message according to the method shown in Figure 3, and can automatically send a message requesting the client to wait if no diagnostic response is received from the next-level node within the time specified by the P2server time parameter, and notify the client to wait, thereby avoiding a diagnostic response timeout and a diagnostic communication failure, thereby solving the above-mentioned defects of the prior art and improving the diagnostic communication success rate.
  • the intermediate node may include a first node, a second node, and a third node.
  • the client and the first node may communicate using a first communication protocol, for example, the first communication protocol is a communication protocol for diagnostic communication over Internet Protocol (DoIP).
  • the second node and the second node may communicate using a second communication protocol,
  • the second communication protocol is a communication protocol for diagnostic communication over Controller Area Network with Flexible Data rate (DoCANFD).
  • DoCANFD Controller Area Network with Flexible Data rate
  • the second node and the third node may communicate using a third communication protocol, for example, the third communication protocol is a communication protocol for diagnostic communication over Controller Area Network (DoCAN).
  • the third node and the diagnosed node may communicate using a fourth communication protocol, for example, the fourth communication protocol is a communication protocol for diagnostic communication over Local Interconnect Network (DoLIN).
  • DoLIN Local Interconnect Network
  • the level of one or more nodes is sequentially reduced in the routing order from the client to the diagnosed node.
  • the diagnostic request message can be routed in the order of the client, one or more nodes with a high to low level, and the diagnosed node.
  • the intermediate node may include a first node, a second node, and a third node with a decreasing level.
  • the diagnostic request message can be routed in the order of the client, the first node, the second node, the third node, and the diagnosed node.
  • the level of one or more nodes is increased in sequence according to the routing order from the client to the diagnosed node.
  • the diagnostic request message is routed in sequence according to the client, one or more nodes with a level from low to high, and the diagnosed node.
  • the intermediate node may include a first node, a second node, and a third node with a level increasing in sequence.
  • the diagnostic request message may be routed in sequence according to the order of the client, the first node, the second node, the third node, and the diagnosed node.
  • Step S220 upon receiving the diagnosis request message, the diagnosed node determines that the routing of the diagnosis request message is completed.
  • the completion of the routing of the diagnosis request message in the embodiment of the present application refers to the successful routing of the diagnosis request message to the diagnosed node.
  • the diagnosed node determines that the routing of the diagnosis request message is completed. At the same time or later, the diagnosed node can determine whether to respond to the diagnosis request message immediately according to the current state of the diagnosed node.
  • the current idle state may include that the current load quantity of the diagnosed node is less than or equal to the preset load quantity, the remaining memory is greater than or equal to the preset remaining memory, the service being executed is about to be completed, and the level of the service requested by the diagnostic request message is higher than the level of other remaining services, etc.
  • a second response can be sent to the client.
  • the second response is used to inform the client that it cannot respond in time and will not respond to the diagnosis request message immediately, that is, it will respond within the time limit of the P2*server_max time parameter (5000 milliseconds).
  • no response can be sent to the client, and a message requesting the client to wait can be sent to the client through the intermediate node.
  • the current busy state may include that the current load of the diagnosed node is greater than the preset load, the remaining memory is less than the preset remaining memory, the service being processed still needs a long time to complete, and there are multiple tasks with a higher level than the service requested by the diagnosis request message after the service being processed.
  • the vehicle diagnostic routing method provided in the embodiment of the present application has the following advantages: during the vehicle diagnostic routing process, if the intermediate node does not receive a diagnostic response from the next-level node within a first timing period, the intermediate node can automatically send a message requesting the client to wait and notify the client to wait, thereby avoiding diagnostic routing and response timeouts and diagnostic communication failures, thereby improving the success rate of diagnostic communication.
  • Defect 1 It is difficult to determine the appropriate P2client parameter value, and a large number of vehicle diagnostic routing stress tests are required, which takes a long time to verify.
  • Defect 2 For any changes involving the diagnostic link, such as changes in the diagnostic link layer, changes in the diagnostic protocol used by each node, and adjustments to the location of each node, the P2client parameter value needs to be readjusted, which has poor flexibility and scalability;
  • Defect 3 When the whole vehicle uses nodes provided by different suppliers, there are differences in the protocol conversion and diagnostic routing capabilities between the nodes, and the P2client parameter values need to be readjusted and verified for the development of each vehicle model.
  • the vehicle diagnostic routing method provided in the embodiment of the present application can automatically trigger client waiting through the above solution, thereby being able to adapt to changes in the diagnostic link and the conversion protocol between each node, and to adapt to the routing differences of each node provided by different suppliers. There is no need to perform a large amount of vehicle diagnostic routing stress testing and verification, thereby solving the above three problems existing in the prior art.
  • the vehicle diagnostic routing method can be applied to the vehicle diagnostic routing system 100 or the vehicle diagnostic routing device 200 or the vehicle diagnostic routing system 300 or the vehicle 400 mentioned below.
  • the vehicle diagnostic routing method may include steps S310 to S370.
  • Step S310 the client sends a diagnosis request message to the diagnosed node, requesting the diagnosed node to perform a diagnosis operation corresponding to the diagnosis request message.
  • the diagnostic services of UDS include 6 categories and a total of 26 types.
  • Each diagnostic service has its own independent diagnostic service identifier (Service Identifier, referred to as SID).
  • SID Service Identifier
  • the diagnostic request message can include the diagnostic service identifier, and the diagnostic service identifier has a corresponding relationship with the diagnostic operation.
  • SID Service Identifier
  • the client may write the diagnostic service identifier corresponding to the diagnostic operation that the client wants to request the diagnosed node to perform and the diagnostic identifier information of the diagnosed node into a diagnostic request message, and send the diagnostic request message.
  • Step S320 the intermediate node routes and forwards the diagnosis request message.
  • the intermediate node is a node between the client and the diagnosed node.
  • the intermediate node can use the method shown in FIG. 3 to route and forward the diagnosis request message.
  • the message is routed and forwarded.
  • step S320 please refer to the above steps S110, S120 and S210.
  • Step S330 upon receiving the diagnosis request message, the diagnosed node determines that the routing of the diagnosis request message is completed.
  • the diagnosed node determines that the routing of the diagnosis request message is completed.
  • Step S340 the diagnosed node performs a diagnostic operation corresponding to the diagnostic request message.
  • the diagnosed node After receiving the diagnosis request message, the diagnosed node parses the diagnosis request message to obtain the diagnosis service identifier corresponding to the diagnosis request message, and performs the diagnosis operation corresponding to the diagnosis service identifier.
  • Step S350 When the diagnostic operation is completed, the diagnosed node sends a diagnostic response message to feed back the diagnostic operation result corresponding to the diagnostic request message to the client.
  • the diagnosed node After the diagnosed node performs the diagnostic operation, a diagnostic result is generated.
  • the diagnostic response message includes the diagnostic result of the diagnostic operation and the diagnostic identification information of the client.
  • the diagnosed node can write the diagnostic identification information of the client and the diagnostic result of the diagnostic operation into the diagnostic response message and send the diagnostic response message.
  • Step S360 the intermediate node routes and forwards the diagnosis response message.
  • the intermediate node includes one or more nodes.
  • the level of one or more nodes decreases in sequence according to the routing order from the client to the diagnosed node.
  • the diagnostic response message is routed in the order of the diagnosed node, one or more nodes with a low to high level, and the client.
  • the level of one or more nodes increases in sequence according to the routing order from the client to the diagnosed node.
  • the diagnostic response message is routed in the order of the diagnosed node, one or more nodes with a high to low level, and the client.
  • Step S370 When receiving the diagnosis response message, the client determines that the diagnosis response message routing is completed.
  • the end of the routing of the diagnostic response message in the embodiment of the present application refers to the successful routing of the diagnostic response message to the client.
  • the client can also obtain the diagnostic result of the diagnostic operation from the diagnostic response message and perform subsequent operations according to the diagnostic result. For example, continue to send new diagnostic request messages to the diagnosed node, or send other diagnostic request messages to other diagnosed nodes.
  • the vehicle diagnostic routing method provided in the embodiment of the present application can automatically trigger client waiting through the above solution, thereby being able to adapt to changes in the conversion protocol between the diagnostic link and each node, and to adapt to the routing differences of each node provided by different suppliers, without the need for a large number of vehicle diagnostic routing stress tests and verifications, thereby solving the above three problems existing in the prior art.
  • FIG. 7 an exemplary embodiment as shown in FIG. 7 is provided here to illustrate the vehicle diagnostic routing method provided by the embodiment of the present application.
  • the client sends a "10 03" request to the diagnosed node, and the "10 03" request passes through the client, the first node, the second node, the third node, and the diagnosed node in sequence to reach the diagnosed node.
  • the diagnosed node executes the same The corresponding diagnostic operation.
  • the first node uses a timer to count after forwarding the "10 03" request. If no diagnostic response is received from the second node within the first timing period, a "7F 10 78" message is sent to the client at a preset period (e.g., 2 seconds) to request the client to wait, and the timer is restarted.
  • a preset period e.g. 2 seconds
  • the second node After forwarding the "10 03" request, the second node uses a timer to count. If the second node does not receive a diagnostic response from the third node within the first timing period, it sends a "7F 10 78" message to the first node at a preset period (for example, 2 seconds), and the timer restarts the timing. When the first node receives the "7F 10 78" message sent by the second node, it forwards the "7F 10 78" message to the client and requests the client to wait.
  • a preset period for example, 2 seconds
  • the third node After forwarding the "10 03" request, the third node uses a timer to count. If the third node does not receive a diagnostic response from the diagnosed node within the first timing period, it sends a "7F 10 78" message to the second node at a preset period (for example, 2 seconds), and the timer restarts the timing.
  • the second node receives the "7F 10 78" message sent by the third node, it forwards the "7F 10 78" message to the first node.
  • the first node receives the "7F 10 78" message sent by the second node, it forwards the "7F 10 78" message to the client, requesting the client to wait.
  • the bold arrows shown in Figure 7 respectively indicate that after the first node, the second node, and the third node send the "7F 10 78" message for the first time, if no diagnostic response from the second node is received within the preset period, the first node, the second node, and the third node send the "7F 10 78" message for the second time.
  • the diagnosed node After the diagnostic operation is completed, the diagnosed node sends a diagnostic response message to the client.
  • the diagnostic response message passes through the diagnosed node, the third node, the second node, the first node, and the client in sequence and finally reaches the client, and the vehicle diagnostic route is completed.
  • each intermediate node automatically triggers the client to wait, thereby extending the diagnostic response time, thereby effectively avoiding diagnostic response timeout and solving the problem of easy failure of diagnostic communication due to diagnostic response timeout.
  • FIG8 is a schematic diagram of the structure of a vehicle diagnostic routing device provided by an embodiment of the present application.
  • the vehicle diagnostic routing device 200 can be applied to an intermediate node in the vehicle diagnostic routing system 100 or an intermediate node or vehicle 400 of the vehicle diagnostic routing system 300 mentioned below.
  • the vehicle diagnostic routing device 200 may include a first message forwarding module 210 and a second message forwarding module 220.
  • the first message forwarding module 210 is used to forward the diagnosis request message when receiving the diagnosis request message sent by the client.
  • the message that the requesting client is waiting for includes a target negative response code, the target negative response code indicating that the diagnostic request message is correctly received, and the target negative response code indicates that the diagnostic request message is correctly received. All parameters are valid, but the requested diagnostic operation has not been completed, and the diagnosed node cannot receive other diagnostic requests temporarily.
  • the second message forwarding module 220 is further configured to determine that a preset condition is satisfied if a diagnosis response from the diagnosed node is received.
  • the second message forwarding module 220 is further configured to determine that a preset condition is satisfied if no diagnostic response is received from the diagnosed node after a second timing duration has expired, and that the second timing duration is greater than the first timing duration.
  • the vehicle diagnostic routing system 300 may be applied to a vehicle 400 to be mentioned below.
  • the vehicle diagnostic routing system 300 may include a client 310, an intermediate node 320, and a diagnosed node 330.
  • the client 310 is used to send a diagnosis request message.
  • the diagnosed node 330 is used to determine that the routing of the diagnosis request message is completed when receiving the diagnosis request message.
  • the level of the one or more nodes is sequentially reduced in the routing order from the client 310 to the diagnosed node 330.
  • the diagnostic request message is routed in the order of the client 310, the one or more nodes from high to low levels, and the diagnosed node 330.
  • the diagnosed node 330 is also used to perform a diagnostic operation corresponding to the diagnostic request message, and send a diagnostic response message when the diagnostic operation is completed.
  • the diagnostic response message is routed in the order of the diagnosed node 330, the one or more nodes from low to high levels, and the client 310.
  • the client 310 is also used to determine that the routing of the diagnostic response message is completed.
  • the coupling, direct coupling or communication connection between the modules shown or discussed may be indirect coupling or communication coupling through some interfaces, devices or modules, and may be electrical, mechanical or other forms, and the embodiments of the present application are not limited to this.
  • the processor 420 may include one or more processing cores.
  • the processor 420 uses various interfaces and lines to connect various parts of the entire vehicle 400, and is used to run or execute instructions, programs, code sets or instruction sets stored in the memory 410, and call to run or execute data stored in the memory 410, perform various functions of the vehicle 400, and process data.
  • the memory 410 may include a random access memory (RAM) or a read-only memory (ROM).
  • the memory 410 may be used to store instructions, programs, codes, code sets or instruction sets.
  • the memory 410 may include a program storage area and a data storage area.
  • the program storage area may store instructions for implementing an operating system, instructions for implementing at least one function, instructions for implementing the above-mentioned various method embodiments, etc.
  • the data storage area may store Stores data created during use of the vehicle 400, etc.
  • the computer readable storage medium 500 can be an electronic memory such as a flash memory, an electrically erasable and programmable read-only memory (Electrically-Erasable Programmable Read-Only Memory, abbreviated as EEPROM), an erasable and programmable read-only memory (Erasable Programmable Read-Only Memory, abbreviated as EPROM), a hard disk or a ROM.
  • EEPROM Electrically erasable and programmable read-only memory
  • EPROM erasable and programmable read-only memory
  • hard disk or a ROM a hard disk or a ROM.
  • the computer-readable storage medium 500 includes a non-transitory computer-readable medium (Non-TCRSM).
  • Non-TCRSM non-transitory computer-readable medium
  • the computer-readable storage medium 500 has storage space for program codes 510 for executing any method steps in the above method. These program codes 510 can be read from or written to one or more computer program products. The program codes 510 can be compressed in an appropriate form.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Health & Medical Sciences (AREA)
  • Computing Systems (AREA)
  • General Health & Medical Sciences (AREA)
  • Medical Informatics (AREA)
  • Mechanical Engineering (AREA)
  • Small-Scale Networks (AREA)

Abstract

本申请实施例提供一种车辆诊断路由方法、装置、系统、车辆及存储介质，涉及诊断通讯技术领域。该方法在接收到客户端发送的诊断请求报文时，客户端和被诊断节点之间的节点转发诊断请求报文；若在第一计时时长内没有接收到下一级节点的诊断应答，向上一级节点发送请求客户端等待的报文，以通知客户端进行等待，直到满足预设条件。从而可以避免诊断路由及响应超时，避免诊断通讯失败，进而可以提升诊断通讯成功率。

Description

车辆诊断路由方法、装置、系统、车辆及存储介质
本申请要求于2022年12月14日提交中国专利局，申请号为202211611417.2，发明名称为“车辆诊断路由方法、装置、系统、车辆及存储介质”的中国专利申请的优先权，其全部内容通过引用结合在本申请中。
技术领域
本申请实施例涉及诊断通讯技术领域，特别地，涉及一种车辆诊断路由方法、装置、系统、车辆及存储介质。
背景技术
随着车辆电子技术的发展，车载网络越来越复杂，车辆诊断通讯链路越来越长，从客户端到被诊断节点之间的中间节点数量也随之增多，导致诊断路由时间长，容易造成诊断响应超时，从而造成诊断通讯失败。
以图1为例(实际车载诊断链路可能更长)，客户端发出的诊断请求报文依次经过客户端、第一节点、第二节点、第三节点、被诊断节点，最终路由至被诊断节点。被诊断节点在收到诊断请求报文后发出诊断响应报文，诊断响应报文依次经过被诊断节点、第三节点、第二节点、第一节点、客户端，最终路由至客户端。如图1所示，诊断请求报文和诊断响应报文的路由总时长超过了期望时长，这会使得客户端在期望时长内无法接收到诊断请求报文对应的诊断响应报文，造成客户端响应超时，从而造成诊断通讯失败。其中，期望时长指的是客户端在成功发出请求之后期望收到响应的时长，在本领域称为P2client。
发明内容
本申请实施例提供一种车辆诊断路由方法、装置、系统、车辆及存储介质，以改善上述问题。
第一方面，本申请实施例提供一种车辆诊断路由方法。该方法包括：在接收到客户端发送的诊断请求报文时，转发所述诊断请求报文；若在第一计时时长内没有接收到下一级节点的诊断应答，向上一级节点发送请求客户端等待的报文，以通知所述客户端进行等待，直到满足预设条件。
第二方面，本申请实施例提供一种车辆诊断路由方法。该方法包括：在客户端发送诊断请求报文后，中间节点按照如权利要求1至5任一项所述的方法对所述诊断请求报文进行路由转发，所述中间节点为所述客户端和被诊断节点之间的节点；在接收到所述诊断请求报文时，所述被诊断节点确定所述诊断请求报文路由结束。
第三方面，本申请实施例提供一种车辆诊断路由装置。该装置包括：第一报 文转发模块，用于在接收到客户端发送的诊断请求报文时，转发所述诊断请求报文；第二报文转发模块，用于若在第一计时时长内没有接收到下一级节点的诊断应答，向上一级节点发送请求客户端等待的报文，以通知所述客户端进行等待，直到满足预设条件。
第四方面，本申请实施例提供一种车辆诊断路由系统。该系统包括：客户端，用于发送诊断请求报文；中间节点，用于按照本申请实施例第一方面提供的方法对所述诊断请求报文进行路由转发，所述中间节点为所述客户端和被诊断节点之间的节点；所述被诊断节点，用于在接收到所述诊断请求报文时，确定所述诊断请求报文路由结束。
第五方面，本申请实施例提供一种车辆。该车辆包括存储器、一个或多个处理器以及一个或多个应用程序。其中，一个或多个应用程序被存储在存储器中，并被配置为当被一个或多个处理器调用时使得一个或多个处理器执行本申请实施例提供的方法。
第六方面，本申请实施例提供一种计算机可读取存储介质。该计算机可读取存储介质中存储有程序代码，该程序代码被配置为当被处理器调用时使得处理器执行本申请实施例提供的方法。
本申请实施例提供一种车辆诊断路由方法、装置、系统、车辆及存储介质，该方法在车辆诊断路由的过程中，客户端和被诊断节点之间的节点可以在第一计时时长内没有接收到下一级节点的诊断应答的情况下，自动发送请求客户端等待的报文，通知客户端进行等待，可以避免诊断路由及响应超时，避免诊断通讯失败，从而可以提升诊断通讯成功率。
附图说明
为了更清楚地说明本申请实施例中的技术方案，下面将对实施例描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本申请的一些实施例，对于本领域技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其它的附图。
图1是本申请一示例性实施例提供的相关车辆诊断路由方法的流程示意图；
图2是本申请一实施例提供的车辆诊断路由系统的结构示意图；
图3是本申请一实施例提供的车辆诊断路由方法的流程示意图；
图4是本申请一实施例提供的车辆诊断路由方法的流程示意图；
图5是本申请一实施例提供的车辆诊断路由方法的流程示意图；
图6是本申请一示例性实施例提供的诊断服务标识的示意图；
图7是本申请一示例性实施例提供的车辆诊断路由方法的流程示意图；
图8是本申请一实施例提供的车辆诊断路由装置的结构示意图；
图9是本申请一实施例提供的车辆诊断路由系统的结构示意图；
图10是本申请一实施例提供的车辆的结构示意图；
图11是本申请一实施例提供的计算机可读取存储介质的结构示意图。
具体实施方式
为了使本技术领域的人员更好地理解本申请方案，下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述。
图2是本申请一实施例提供的车辆诊断路由系统的结构示意图。该车辆诊断路由系统100可以应用于车辆，用于实施本申请实施例提供的车辆诊断路由方法。车辆诊断路由系统100可以包括客户端110、中间节点120以及被诊断节点130。客户端110可以发起诊断请求报文，诊断请求报文经过中间节点120路由转发，最终路由至被诊断节点130处。被诊断节点130按照诊断请求报文执行客户端110所请求的诊断操作，在诊断操作执行完毕之后，发出诊断响应报文。诊断响应报文经过中间节点120路由转发，最终路由至客户端110。
本申请实施例中的客户端110、中间节点120、被诊断节点130可以包括但不限于车辆上的各电子控制单元(Electronic Control Unit，简称ECU)、微控制单元(Microcontroller Unit，简称MCU)、整车控制器(Vehicle control unit，简称VCU)、区域控制器(Zone Control Unit，简称ZCU)等。客户端110还可以是与车辆外接的电子设备，例如，诊断仪或其他测试器。此外，本申请实施例中的中间节点可以包括一个或多个节点。
图3是本申请一实施例提供的车辆诊断路由方法的流程示意图。该车辆诊断路由方法可以应用于车辆诊断路由系统100中的中间节点120或下文将会提到的车辆诊断路由装置200或车辆诊断路由系统300中的中间节点320或车辆400。该车辆诊断路由方法可以包括以下步骤S110和步骤S120。
步骤S110，在接收到客户端发送的诊断请求报文时，转发诊断请求报文。
本申请实施例中的诊断请求报文指的是客户端向被诊断节点发送的用于指示被诊断节点执行对应的诊断操作的报文。诊断请求报文可以包括被诊断节点的诊断标识(Identity document，简称Id)信息，诊断标识信息用于唯一标识各节点。
本申请实施例中的执行主体(例如，中间节点)本地存储有子网路由标识表，子网路由标识表可以包括节点自身的诊断标识信息以及该节点的所有下级节点的诊断标识信息。其中，下级节点指的是从客户端至被诊断节点之间的路由过程中，诊断请求报文经过当前节点路由转发之后需要经过或到达的节点，下级节点可以包括被诊断节点。例如，当前节点(第一节点)的下级节点包括第二节点、第三节点以及被诊断节点，则第一节点的子网路由标识表可以包括第一节点、第二节点、第三节点以及被诊断节点的诊断标识信息，而第二节点的子网路由标识表可以包括第二节点、第三节点以及被诊断节点的诊断标识信息，第三节点的子网路由标识表可以包括第三节点和被诊断节点的诊断标识信息。被诊断节点可以根据实际需求设置其是否具备子网路由标识表。
在接收到客户端发送的诊断请求报文时。可以根据被诊断节点的诊断标识信息在子网路由标识表中查找下一级节点的诊断标识信息。根据下一级节点的 诊断标识信息，向下一级节点转发诊断请求报文。其中，下一级节点可能是中间节点，也可能是被诊断节点。
步骤S120，若在第一计时时长内没有接收到下一级节点的诊断应答，向上一级节点发送请求客户端等待的报文，以通知客户端进行等待，直到满足预设条件。
本申请实施例中的下一级节点的诊断应答可以是下一级节点的任何应答。例如，下一级节点的应答可以是被诊断节点的任何诊断应答，下一级节点的应答也可以是下一级节点发送的请求客户端等待的报文。
本申请实施例中的请求客户端等待的报文可以包括目标否定响应码(Negative Response Code，简称NRC)。目标NRC指的是统一诊断服务(Unified Diagnostic Services，简称UDS)中的请求已被正确接收-回复待定(Request Correctly Received-Response Pending，简称RCRRP)的NRC。目标NRC用于表征诊断请求报文被正确接收，诊断请求报文中的所有参数均有效，但是所请求的诊断操作尚未完成，被诊断节点暂时不能接收其他诊断请求。一旦请求的服务已经完成，被诊断节点应该发送一个积极响应或消极响应，积极响应或消极响应的代码应与目标NRC不同。目标NRC的消极响应可以被被诊断节点重复，直到客户端所请求的诊断操作完成并且被诊断节点发送的诊断响应报文被发送。需要说明的是，根据实际需求，也可以设置其他特定的用于请求客户端等待但不包括目标NRC的报文。
在路由转发诊断请求报文之后，可以采用计时器(例如，P2server定时器)进行计时。若在第一计时时长内没有接收到下一级节点的诊断应答，则可以采用被诊断节点的诊断响应标识(Identity document，简称Id)，例如诊断响应标识可以是“0x785”，以预设周期向上一级节点发送请求客户端等待的报文。通过采用被诊断节点的诊断响应Id发送客户端等待的报文，可以模拟被诊断节点向客户端发送请求客户端等待的响应，从而延长被诊断节点的响应时长，避免响应超时造成诊断通讯失败。
本申请实施例中的第一计时时长可以指P2server定时器的时间参数所限定的时长。P2server定时器的时间参数包括P2server_max时间参数和P2*server_max时间参数，通常P2server_max时间参数所限定的时长为50毫秒，P2*server_max时间参数所限定的时长为5000毫秒。通过P2server_max时间参数和P2*server_max时间参数，客户端可以知道其发送的诊断请求报文会在多长时间内响应，如果超过了P2server定时器的时间参数还没有接收到被诊断节点的响应，则客户端可报错。例如，客户端请求“10 03”之后被诊断节点响应“50 03 00 32 01 F4”指的是被诊断节点告知客户端会在P2server_max时间参数内发送响应，但是当被诊断节点忙于处于其他事情而暂时没空对客户端的诊断请求报文作出响应时，会在P2*server_max参数时间内发送响应。
本申请实施例中的预设周期指的是请求客户端等待的报文的发送时间间隔。预设周期可以根据实际需求进行设定，例如预设周期可以是2秒。
本申请实施例中的预设条件指的是不用继续发送请求客户端等待的报文的条件，在满足预设条件时不再继续发送请求客户端等待的报文。在一些实施方式中，若接收到被诊断节点的诊断应答，确定满足预设条件。在一些实施方式中，若在超过第二计时时长后仍没有接收到被诊断节点的诊断应答，确定满足预设条件，第二计时时长大于第一计时时长，第二计时时长指的是最大超时值(timeout)，例如第二计时时长为60秒。上述被诊断节点的诊断应答可以指被诊断节点的任何应答，可以包括积极响应或消极响应。
本申请实施例提供的车辆诊断路由方法，在车辆诊断路由的过程中，客户端和被诊断节点之间的节点可以在第一计时时长内没有接收到下一级节点的诊断应答的情况下，自动发送请求客户端等待的报文，通知客户端进行等待，可以避免诊断路由及响应超时，避免诊断通讯失败，从而可以提升诊断通讯成功率。
图4是本申请一实施例提供的车辆诊断路由方法的流程示意图。该车辆诊断路由方法可以应用于上述车辆诊断路由系统100或下文将会提到的车辆诊断路由装置200或车辆诊断路由系统300或车辆400。该车辆诊断路由方法可以包括以下步骤S210和步骤S220。
步骤S210，在客户端发送诊断请求报文后，中间节点对诊断请求报文进行路由转发，中间节点为客户端和被诊断节点之间的节点。
其中，中间节点按照如图3所示的车辆诊断路由方法对诊断请求报文进行路由转发，具体描述请参阅上述步骤S110和步骤S120，在此不再赘述。
本申请实施例中的中间节点可以包括一个或多个节点。一个或多个节点中的每个节点可以包括子网路由标识表。每个节点的子网路由标识表可以包括节点自身的诊断标识信息以及所有下级节点的诊断标识信息。其中下级节点的具体描述请参阅上述步骤S110中的相关部分。
在一些实施方式中，为了提升车辆诊断路由效率，客户端、一个或多个节点、被诊断节点中的相邻两个节点之间可以采用相同的通信协议。
在一些实施方式中，为了兼顾各节点的功能和成本需求，客户端、一个或多个节点、被诊断节点中的相邻两个节点之间可以采用不同的通信协议。现有技术在客户端、一个或多个节点、被诊断节点中的相邻两个节点之间可以采用不同的通信协议的情况下，由于诊断路由还涉及协议转化，诊断响应时间较长，容易导致诊断响应超时造成诊断通讯失败。然而本申请中的中间节点按照图3所示的方法对诊断请求报文进行路由转发，可以在P2server时间参数所限定的时间内没有接收到下一级节点的诊断应答的情况下，自动发送请求客户端等待的报文，通知客户端进行等待，从而可以避免诊断响应超时，避免诊断通讯失败，从而可以解决现有技术的上述缺陷，并可以提升诊断通讯成功率。
作为一种示例，中间节点可以包括第一节点、第二节点以及第三节点。客户端与第一节点之间可以采用第一通信协议进行通信，例如，第一通信协议为通过网络协议进行诊断通信(Diagnostic communication over Internet Protocol，简称DoIP)的通信协议。第二节点和第二节点之间可以采用第二通信协议进行通信， 例如，第二通信协议为通过具有灵活数据速率的控制器域网进行诊断通信(Diagnostic communication over Controller Area Network with Flexible Data rate，简称DoCANFD)的通信协议。第二节点和第三节点之间可以采用第三通信协议进行通信，例如，第三通信协议为通过控制器域网进行诊断通信(Diagnostic communication over Controller Area Network，简称DoCAN)的通信协议。第三节点和被诊断节点之间可以采用第四通信协议进行通信，例如，第四通信协议为通过局域交互网络进行诊断通信(Diagnostic communication over Local Interconnect Network，简称DoLIN)的通信协议。
在一些实施方式中，一个或多个节点的级别按照从客户端至被诊断节点的路由顺序依次降低。可以按照客户端、级别由高至低的一个或多个节点以及被诊断节点的顺序依次对诊断请求报文进行路由。例如，中间节点可以包括级别依次降低的第一节点、第二节点以及第三节点。可以按照客户端、第一节点、第二节点、第三节点、被诊断节点的顺序依次对诊断请求报文进行路由。
在一些实施方式中，一个或多个节点的级别按照从客户端至被诊断节点的路由顺序依次升高。诊断请求报文按照客户端、级别由低至高的一个或多个节点以及被诊断节点的顺序依次进行路由。例如，中间节点可以包括级别依次升高的第一节点、第二节点以及第三节点。可以按照客户端、第一节点、第二节点、第三节点、被诊断节点的顺序依次对诊断请求报文进行路由。
通过设置中间节点的多个节点的级别，可以便于分别对各节点的子网路由标识表所包括的节点的诊断标识信息进行设置，无需将每个节点的子网路由标识表均设置为包括所有节点的诊断标识信息，从而可以系统资源，同时也便于在子网路由标识表中快速查找下一级节点，提升整体诊断路由效率。
步骤S220，在接收到诊断请求报文时，被诊断节点确定诊断请求报文路由结束。
本申请实施例中的诊断请求报文路由结束指的是诊断请求报文成功路由至被诊断节点。
在接收到诊断请求报文时，被诊断节点确定诊断请求报文路由结束，与此同时或之后，被诊断节点可以根据被诊断节点的当前状态来确定是否立即对诊断请求报文作出响应。
若被诊断节点的当前状态空闲，可以向客户发送第一响应用于通知客户端会立即对诊断请求报文作出响应，也即会在P2server_max时间参数(50毫秒)所限定的时长内作出响应。其中，当前状态空闲可以包括被诊断节点当前负载数量小于或等于预设负载数量，内存剩余量大于或等于预设剩余量，正在执行的服务即将完成且诊断请求报文所请求的服务的级别高于其他剩余服务的级别等。
若被诊断节点的当前状态繁忙，可以向客户端发送第二响应，第二响应用于通知客户端当前无法及时作出响应，不会立即对诊断请求报文作出响应，也即会在P2*server_max时间参数(5000毫秒)所限定的时长内作出响应。或者也可以不向客户端发送任何响应，通过中间节点向客户端发送请求客户端等待的报文 来延长响应时间。其中，当前状态繁忙可以包括被诊断节点当前负载数量大于预设负载数量，内存剩余量小于预设剩余量，正在处理的服务还需较长时间完成，正在处理的服务之后还存在多个级别高于诊断请求报文所请求的服务的级别的任务等。
本申请实施例提供的车辆诊断路由方法，在车辆诊断路由的过程中，中间节点可以在第一计时时长内没有接收到下一级节点的诊断应答的情况下，自动发送请求客户端等待的报文，通知客户端进行等待，可以避免诊断路由及响应超时，避免诊断通讯失败，从而可以提升诊断通讯成功率。
针对多级联复杂网络车辆诊断路由容易诊断响应超时的问题，现有技术大多采用将P2client参数值(上述期望时长)调大，并通过大量整车诊断路由压力测试验证P2client参数值的有效性的方法。这种方法存在以下三个缺陷：
缺陷1：难以确定合适的P2client参数值，需要进行大量整车诊断路由压力测试验证，验证周期长；
缺陷2：针对任何涉及诊断链路的变化，例如，诊断链路层的变化、各节点采用的诊断协议的变化，各节点位置的调整，需要重新调整P2client参数值，灵活性和扩展性较差；
缺陷3：在整车采用不同供应厂商提供的各节点的情况下，各节点之间的协议转化和诊断路由能力存在差异，各车型开发需要重新调整与验证P2client参数值。
相比于现有技术针对多级联复杂网络车辆诊断路由提出的将P2client参数值调大来避免诊断响应超时的方案，本申请实施例提供的车辆诊断路由方法通过上述方案可以实现自动触发客户端等待，从而可以自适应诊断链路和各节点之间的转化协议的变更，自适应不同供应商提供的各节点的路由差异，无需进行大量整车诊断路由压力测试验证，进而可以解决现有技术存在的上述三个问题。
图5是本申请一实施例提供的车辆诊断路由方法的流程示意图。该车辆诊断路由方法可以应用于上述车辆诊断路由系统100或下文将会提到的车辆诊断路由装置200或车辆诊断路由系统300或车辆400。该车辆诊断路由方法可以包括步骤S310至步骤S370。
步骤S310，客户端向被诊断节点发出诊断请求报文，请求被诊断节点执行与诊断请求报文对应的诊断操作。
如图6所示，UDS的诊断服务包含6大类共26种，每种诊断服务都有自己独立的诊断服务标识(Service Identifier，简称SID)。诊断请求报文可以包括诊断服务标识，诊断服务标识与诊断操作具有对应关系。其他关于诊断请求报文的具体描述请参阅上述相关部分。
客户端可以将想要请求被诊断节点执行的诊断操作对应的诊断服务标识以及被诊断节点的诊断标识信息写入诊断请求报文中，并发出该诊断请求报文。
步骤S320，中间节点对诊断请求报文进行路由转发，中间节点为客户端和被诊断节点之间的节点。其中，中间节点可以采用图3所示的方法对诊断请求 报文进行路由转发，步骤S320的具体描述请参阅上述步骤S110、步骤S120以及步骤S210。
步骤S330，在接收到诊断请求报文时，被诊断节点确定诊断请求报文路由结束。该步骤S330的具体描述请参阅上述步骤S220。
步骤S340，被诊断节点被诊断节点执行与诊断请求报文对应的诊断操作。
被诊断节点在接收到诊断请求报文后，对诊断请求报文进行解析，可以得到诊断请求报文对应的诊断服务标识，并执行与诊断服务标识对应的诊断操作。
步骤S350，在诊断操作执行完毕时，被诊断节点发出诊断响应报文，向客户端反馈与诊断请求报文对应的诊断操作结果。
被诊断节点执行诊断操作后会生成诊断结果。诊断响应报文包括诊断操作的诊断结果和客户端的诊断标识信息。被诊断节点可以将客户端的诊断标识信息和诊断操作的诊断结果写入诊断响应报文中，并发出该诊断响应报文。
步骤S360，中间节点对诊断响应报文进行路由转发。
如前所述，中间节点包括一个或多个节点。在一些实施方式中，一个或多个节点的级别按照从客户端至被诊断节点的路由顺序依次降低。诊断响应报文按照被诊断节点、级别由低至高的一个或多个节点、客户端的顺序依次进行路由。在一些实施方式中，一个或多个节点的级别按照从客户端至被诊断节点的路由顺序依次升高。诊断响应报文按照被诊断节点、级别由高至低的一个或多个节点、客户端的顺序依次进行路由。
步骤S370，在接收到所述诊断响应报文时，客户端确定诊断响应报文路由结束。
本申请实施例中的诊断响应报文路由结束指的是诊断响应报文成功路由至客户端。客户端在接收到诊断响应报文后，还可以从诊断响应报文中获取诊断操作的诊断结果，根据诊断结果执行后续操作。例如，继续向被诊断节点发送新的诊断请求报文，或者向其他被诊断节点发送其他诊断请求报文。
本申请实施例提供的车辆诊断路由方法，在车辆诊断路由的过程中，客户端和被诊断节点之间的节点可以在第一计时时长内没有接收到下一级节点的诊断应答的情况下，自动发送请求客户端等待的报文，通知客户端进行等待，可以避免诊断路由及响应超时，避免诊断通讯失败，从而可以提升诊断通讯成功率。相比于现有技术针对多级联复杂网络车辆诊断路由提出的将P2client参数值调大来避免诊断响应超时的方案，本申请实施例提供的车辆诊断路由方法通过上述方案可以实现自动触发客户端等待，从而可以自适应诊断链路和各节点之间的转化协议的变更，自适应不同供应商提供的各节点的路由差异，无需进行大量整车诊断路由压力测试验证，进而可以解决现有技术存在的上述三个问题。
为便于理解，在此提供如图7所示的示例性实施例来说明本申请实施例提供的车辆诊断路由方法。如图7所示，客户端向被诊断节点发出“10 03”请求，“10 03”请求依次经过客户端、第一节点、第二节点、第三节点、被诊断节点到达被诊断节点。被诊断节点在接收到“10 03”请求后，执行与“10 03”请求 对应的诊断操作。
在“10 03”请求路由的过程中，第一节点在转发“10 03”请求后，采用计时器进行计时。若在第一计时时长内没有接收到第二节点的诊断应答，则以预设周期(例如2秒)向客户端发送“7F 10 78”报文，请求客户端进行等待，此时计时器重新进行计时。
第二节点在转发“10 03”请求后，采用计时器进行计时。第二节点若在第一计时时长内没有接收到第三节点的诊断应答，则以预设周期(例如2秒)向第一节点发送“7F 10 78”报文，此时计时器重新进行计时。第一节点在接收到第二节点发送的“7F 10 78”报文时，将“7F 10 78”报文转发至客户端，请求客户端进行等待。
第三节点在转发“10 03”请求后，采用计时器进行计时。第三节点若在第一计时时长内没有接收到被诊断节点的诊断应答，则以预设周期(例如2秒)向第二节点发送“7F 10 78”报文，此时计时器重新进行计时。第二节点在接收到第三节点发送的“7F 10 78”报文时将“7F 10 78”报文转发至第一节点，第一节点在接收到第二节点发送的“7F 10 78”报文时将“7F 10 78”报文转发至客户端，请求客户端进行等待。
图7所示的加粗箭头分别表示第一节点、第二节点、第三节点在第一次发送“7F 10 78”报文后，在预设周期仍没有接收到第二节点的诊断应答的情况下，第二次发送“7F 10 78”报文。
被诊断节点在诊断操作执行完毕之后，向客户端发出诊断响应报文，该诊断响应报文依次经过被诊断节点、第三节点、第二节点、第一节点、客户端最终到达客户端，本次车辆诊断路由结束。
可见，在本申请实施例提供的车辆诊断路由方法中，各中间节点采用自动触发客户端进行等待的方式，延长诊断响应时间，从而可以有效避免诊断响应超时，解决由于诊断响应超时导致的诊断通讯容易失败的问题。
图8是本申请一实施例提供的车辆诊断路由装置的结构示意图。车辆诊断路由装置200可以应用于车辆诊断路由系统100中的中间节点或下文将会提到的车辆诊断路由系统300的中间节点或车辆400。车辆诊断路由装置200可以包括第一报文转发模块210和第二报文转发模块220。
第一报文转发模块210，用于在接收到客户端发送的诊断请求报文时，转发所述诊断请求报文。
第二报文转发模块220，用于若在第一计时时长内没有接收到下一级节点的诊断应答，向上一级节点发送请求客户端等待的报文，以通知所述客户端进行等待，直到满足预设条件。
在一些实施方式中，第二报文转发模块220，还用于采用被诊断节点的诊断响应标识，以预设周期向上一级节点发送请求客户端等待的报文。
在一些实施方式中，所述请求客户端等待的报文包括目标否定响应码，所述目标否定响应码表征所述诊断请求报文被正确接收，所述诊断请求报文中的所 有参数均有效，但是所请求的诊断操作尚未完成，所述被诊断节点暂时不能接收其他诊断请求。
在一些实施方式中，第二报文转发模块220，还用于若接收到被诊断节点的诊断应答，确定满足预设条件。
在一些实施方式中，第二报文转发模块220，还用于若在超过第二计时时长后仍没有接收到被诊断节点的诊断应答，确定满足预设条件，所述第二计时时长大于所述第一计时时长。
图9是本申请一实施例提供的车辆诊断路由系统的结构示意图。车辆诊断路由系统300可以应用于下文将会提到的车辆400。车辆诊断路由系统300可以包括客户端310、中间节点320以及被诊断节点330。
客户端310，用于发送诊断请求报文。
中间节点320，用于按照图3所示的车辆诊断路由方法对所述诊断请求报文进行路由转发，所述中间节点320为所述客户端310和被诊断节点330之间的节点。
被诊断节点330，用于在接收到所述诊断请求报文时，确定所述诊断请求报文路由结束。
需要说明的是，车辆诊断路由系统300可以与上述车辆诊断路由系统100相同，客户端310可以与客户端110相同，中间节点320可以与上述中间节点120相同，被诊断节点330可以与被诊断节点130相同。
在一些实施方式中，所述中间节点320包括所述一个或多个节点。
在一些实施方式中，所述一个或多个节点中的每个节点包括子网路由标识表，每个节点的子网路由标识表包括节点自身的诊断标识信息以及所有下级节点的诊断标识信息。
在一些实施方式中，所述客户端310、所述一个或多个节点以及所述被诊断节点330中的相邻两个节点之间采用相同的通信协议。
在一些实施方式中，所述客户端310、所述一个或多个节点以及所述被诊断节点330中的相邻两个节点之间采用不同的通信协议。
在一些实施方式中，所述一个或多个节点的级别按照从所述客户端310至所述被诊断节点330的路由顺序依次降低。所述诊断请求报文按照所述客户端310、级别由高至低的所述一个或多个节点以及所述被诊断节点330的顺序依次进行路由。被诊断节点330还用于执行与诊断请求报文对应的诊断操作，在诊断操作执行完毕时，发送诊断响应报文。所述诊断响应报文按照所述被诊断节点330、级别由低至高的所述一个或多个节点以及所述客户端310的顺序依次进行路由。在接收到所述诊断响应报文时，所述客户端310还用于确定所述诊断响应报文路由结束。
在一些实施方式中，所述一个或多个节点的级别按照从所述客户端至所述被诊断节点的路由顺序依次升高。所述诊断请求报文按照所述客户端310、级别由低至高的所述一个或多个节点以及所述被诊断节点330的顺序依次进行路由。 被诊断节点330还用于执行与诊断请求报文对应的诊断操作，在诊断操作执行完毕时，发送诊断响应报文。所述诊断响应报文按照所述被诊断节点330、级别由高至低的所述一个或多个节点以及所述客户端310的顺序依次进行路由。在接收到所述诊断响应报文时，所述客户端310还用于确定所述诊断响应报文路由结束。
本领域技术人员可以清楚地了解到，本申请实施例提供的车辆诊断路由装置200可以实现图3所示的车辆诊断路由方法，本申请实施例提供的车辆诊断路由系统300可以本申请实施例提供的车辆诊断路由方法。上述装置和模块的具体工作过程，可以参阅对应的车辆诊断路由方法对应的过程，在此不再赘述。
本申请提供的实施例中，所显示或讨论的模块相互之间的耦合、直接耦合或者通信连接，可以是通过一些接口、装置或模块的间接耦合或通信耦合，可以是电性、机械或其他形式，本申请实施例对此不作限制。
另外，在本申请实施例中的各功能模块可以集成在一个处理模块中，也可以是各个模块单独物理存在，也可以两个或两个以上模块集成在一个模块中。上述集成的模块既可以采用硬件的形式实现，也可以采用软件的功能模块的形式实现，本申请实施例在此不作限制。
图10是本申请一实施例提供的车辆的结构示意图。该车辆400可以包括一个或多个如下部件：存储器410、一个或多个处理器420以及一个或多个应用程序，其中一个或多个应用程序可以被存储在存储器410中并被配置为当被一个或多个处理器420调用时，使得一个或多个处理器420执行本申请实施例提供的上述车辆诊断路由方法。
处理器420可以包括一个或多个处理核。处理器420利用各种接口和线路连接整个车辆400内各个部分，用于运行或执行存储在存储器410内的指令、程序、代码集或指令集，以及调用运行或执行存储在存储器410内的数据，执行车辆400的各种功能和处理数据。
处理器420可以采用数字信号处理(Digital Signal Processing，简称DSP)、现场可编程门阵列(Field-Programmable Gate Array，简称FPGA)、可编辑逻辑阵列(Programmable Logic Array，简称PLA)中的至少一种硬件形式来实现。
处理器420可集成中央处理器(Central Processing Unit，简称CPU)、图像处理器(Graphics Processing Unit，简称GPU)和调制解调器中的一种或几种的组合。其中，CPU主要处理操作系统、用户界面和应用程序等；GPU用于负责显示内容的渲染和绘制；调制解调器用于处理无线通信。可以理解的是，上述调制解调器也可以不集成于处理器420中，单独通过一块通信芯片进行实现。
存储器410可以包括随机存储器(Random Access Memory，简称RAM)，也可以包括只读存储器(Read-Only Memory，简称ROM)。存储器410可以用于存储指令、程序、代码、代码集或指令集。存储器410可以包括存储程序区和存储数据区。其中，存储程序区可以存储用于实现操作系统的指令、用于实现至少一个功能的指令、用于实现上述各个方法实施例的指令等。存储数据区可以存 储车辆400在使用中所创建的数据等。
图11是本申请一实施例提供的计算机可读取存储介质的结构示意图。该计算机可读取存储介质500中存储有程序代码510，该程序代码510被配置为当被处理器调用时，使得处理器执行本申请实施例提供的上述车辆诊断路由方法。
计算机可读取存储介质500可以是诸如闪存、电可擦除可编辑只读存储器(Electrically-Erasable Programmable Read-Only Memory，简称EEPROM)、可擦除可编辑只读存储器(Erasable Programmable Read-Only Memory，简称EPROM)、硬盘或者ROM之类的电子存储器。
在一些实施方式中，计算机可读取存储介质500包括非易失性计算机可读介质(Non-Transitory Computer-Readable Storage Medium，简称Non-TCRSM)。计算机可读取存储介质500具有执行上述方法中的任何方法步骤的程序代码510的存储空间。这些程序代码510可以从一个或者多个计算机程序产品中读出或者写入到这一个或者多个计算机程序产品中。程序代码510可以以适当的形式进行压缩。
综上所述，本申请实施例提供一种车辆诊断路由方法、装置、系统、车辆及存储介质，涉及诊断通讯技术领域。该方法在接收到客户端发送的诊断请求报文时，客户端和被诊断节点之间的节点转发诊断请求报文；若在第一计时时长内没有接收到下一级节点的诊断应答，向上一级节点发送请求客户端等待的报文，以通知客户端进行等待，直到满足预设条件。从而可以避免诊断路由及响应超时，避免诊断通讯失败，进而可以提升诊断通讯成功率。
最后应说明的是：以上实施例仅用于说明本申请的技术方案，而非对其限制。尽管参照前述实施例对本申请进行了详细的说明，本领域技术人员应当理解：其依然可以对前述各实施例所记载的技术方案进行修改，或者对其中部分技术特征进行等同替换；而这些修改或者替换，并不驱使相应技术方案的本质脱离本申请各实施例技术方案的精神和范围。

Claims (16)

  1. 一种车辆诊断路由方法，其特征在于，包括：
    在接收到客户端发送的诊断请求报文时，转发所述诊断请求报文；
    若在第一计时时长内没有接收到下一级节点的诊断应答，向上一级节点发送请求客户端等待的报文，以通知所述客户端进行等待，直到满足预设条件。
  2. 根据权利要求1所述的方法，其特征在于，所述向上一级节点发送请求客户端等待的报文，包括：
    采用被诊断节点的诊断响应标识，以预设周期向上一级节点发送请求客户端等待的报文。
  3. 根据权利要求2所述的方法，其特征在于，所述请求客户端等待的报文包括目标否定响应码，所述目标否定响应码表征所述诊断请求报文被正确接收，所述诊断请求报文中的所有参数均有效，但是所请求的诊断操作尚未完成，所述被诊断节点暂时不能接收其他诊断请求。
  4. 根据权利要求1所述的方法，其特征在于，所述转发所述诊断请求报文之后，所述方法还包括：
    若接收到被诊断节点的诊断应答，确定满足预设条件。
  5. 根据权利要求1或4所述的方法，其特征在于，所述转发所述诊断请求报文之后，所述方法还包括：
    若在超过第二计时时长后仍没有接收到被诊断节点的诊断应答，确定满足预设条件，所述第二计时时长大于所述第一计时时长。
  6. 一种车辆诊断路由方法，其特征在于，包括：
    在客户端发送诊断请求报文后，中间节点按照如权利要求1至5任一项所述的方法对所述诊断请求报文进行路由转发，所述中间节点为所述客户端和被诊断节点之间的节点；
    在接收到所述诊断请求报文时，所述被诊断节点确定所述诊断请求报文路由结束。
  7. 根据权利要求6所述的方法，其特征在于，所述中间节点包括所述一个或多个节点。
  8. 根据权利要求7所述的方法，其特征在于，所述一个或多个节点的级别按照从所述客户端至所述被诊断节点的路由顺序依次降低。
  9. 根据权利要求8所述的方法，其特征在于，所述一个或多个节点中的每个节点包括子网路由标识表，每个节点的子网路由标识表包括节点自身的诊断标识信息以及所有下级节点的诊断标识信息。
  10. 根据权利要求7所述的方法，其特征在于，所述客户端、所述一个或多个节点以及所述被诊断节点中的相邻两个节点之间采用不同的通信协议。
  11. 根据权利要求8至10任一项所述的方法，其特征在于，所述诊断请求报文按照所述客户端、级别由高至低的所述一个或多个节点以及所述被诊断节 点的顺序依次进行路由。
  12. 根据权利要求11所述的方法，其特征在于，在所述被诊断节点确定所述诊断请求报文路由结束之后，所述方法还包括：
    所述被诊断节点发送诊断响应报文；
    所述诊断响应报文按照所述被诊断节点、级别由低至高的所述一个或多个节点以及所述客户端的顺序依次进行路由；
    在接收到所述诊断响应报文时，所述客户端确定所述诊断响应报文路由结束。
  13. 一种车辆诊断路由装置，其特征在于，包括：
    第一报文转发模块，用于在接收到客户端发送的诊断请求报文时，转发所述诊断请求报文；
    第二报文转发模块，用于若在第一计时时长内没有接收到下一级节点的诊断应答，向上一级节点发送请求客户端等待的报文，以通知所述客户端进行等待，直到满足预设条件。
  14. 一种车辆诊断路由系统，其特征在于，包括：
    客户端，用于发送诊断请求报文；
    中间节点，用于按照如权利要求1至5任一项所述的方法对所述诊断请求报文进行路由转发，所述中间节点为所述客户端和被诊断节点之间的节点；
    所述被诊断节点，用于在接收到所述诊断请求报文时，确定所述诊断请求报文路由结束。
  15. 一种车辆，其特征在于，包括：
    存储器；
    一个或多个处理器；
    一个或多个应用程序，其中，所述一个或多个应用程序存储在所述存储器中，并被配置为当被所述一个或多个处理器调用时，使得所述一个或多个处理器执行如权利要求1至12任一项所述的方法。
  16. 一种计算机可读取存储介质，其特征在于，所述计算机可读取存储介质中存储有程序代码，所述程序代码被配置为当被处理器调用时，使得所述处理器执行如权利要求1至12任一项所述的方法。
PCT/CN2023/115500 2022-12-14 2023-08-29 车辆诊断路由方法、装置、系统、车辆及存储介质 Ceased WO2024124964A1 (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
EP23902172.8A EP4629602A4 (en) 2022-12-14 2023-08-29 VEHICLE DIAGNOSTIC ROUTING METHOD AND APPARATUS, AND SYSTEM, VEHICLE AND STORAGE SUPPORT

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN202211611417.2A CN118200400A (zh) 2022-12-14 2022-12-14 车辆诊断路由方法、装置、系统、车辆及存储介质
CN202211611417.2 2022-12-14

Publications (1)

Publication Number Publication Date
WO2024124964A1 true WO2024124964A1 (zh) 2024-06-20

Family

ID=91393655

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2023/115500 Ceased WO2024124964A1 (zh) 2022-12-14 2023-08-29 车辆诊断路由方法、装置、系统、车辆及存储介质

Country Status (3)

Country Link
EP (1) EP4629602A4 (zh)
CN (1) CN118200400A (zh)
WO (1) WO2024124964A1 (zh)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN119270825A (zh) * 2024-10-08 2025-01-07 重庆赛力斯凤凰智创科技有限公司 一种车辆自动化测试方法、装置、电子设备及存储介质
CN119520339A (zh) * 2024-12-12 2025-02-25 长城汽车股份有限公司 一种设备测试方法、装置及系统

Families Citing this family (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN118859900B (zh) * 2024-07-03 2026-02-13 深圳市元征科技股份有限公司 应答反馈方法、装置、终端设备以及储介质
CN121441930A (zh) * 2024-07-30 2026-01-30 博世创新软件开发(无锡)有限公司 Sovd服务器及其执行的方法
CN119109759B (zh) * 2024-08-26 2026-03-10 奇瑞汽车股份有限公司 Can网络通信诊断方法、装置及车辆

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH08163670A (ja) * 1994-12-06 1996-06-21 Nippondenso Co Ltd 車両用通信システム
JP2015228622A (ja) * 2014-06-02 2015-12-17 株式会社デンソー 車載ネットワークシステム及び車載中継装置
CN114253251A (zh) * 2022-01-20 2022-03-29 深圳市元征科技股份有限公司 车辆远程诊断方法、装置、设备连接器及存储介质
CN115016444A (zh) * 2022-07-26 2022-09-06 深圳市元征科技股份有限公司 一种车辆远程诊断方法及相关组件
CN115032972A (zh) * 2022-08-10 2022-09-09 深圳市星卡软件技术开发有限公司 车辆诊断数据的通信方法、装置、电子设备及介质

Family Cites Families (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP6717184B2 (ja) * 2016-12-15 2020-07-01 株式会社デンソー 車載制御装置

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH08163670A (ja) * 1994-12-06 1996-06-21 Nippondenso Co Ltd 車両用通信システム
JP2015228622A (ja) * 2014-06-02 2015-12-17 株式会社デンソー 車載ネットワークシステム及び車載中継装置
CN114253251A (zh) * 2022-01-20 2022-03-29 深圳市元征科技股份有限公司 车辆远程诊断方法、装置、设备连接器及存储介质
CN115016444A (zh) * 2022-07-26 2022-09-06 深圳市元征科技股份有限公司 一种车辆远程诊断方法及相关组件
CN115032972A (zh) * 2022-08-10 2022-09-09 深圳市星卡软件技术开发有限公司 车辆诊断数据的通信方法、装置、电子设备及介质

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
See also references of EP4629602A4 *

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN119270825A (zh) * 2024-10-08 2025-01-07 重庆赛力斯凤凰智创科技有限公司 一种车辆自动化测试方法、装置、电子设备及存储介质
CN119520339A (zh) * 2024-12-12 2025-02-25 长城汽车股份有限公司 一种设备测试方法、装置及系统

Also Published As

Publication number Publication date
EP4629602A1 (en) 2025-10-08
EP4629602A4 (en) 2026-04-15
CN118200400A (zh) 2024-06-14

Similar Documents

Publication Publication Date Title
EP4629602A1 (en) Vehicle diagnostic routing method and apparatus, and system, vehicle and storage medium
US12034604B2 (en) MQTT protocol simulation method and simulation device
CN103338118B (zh) 一种通信网络连接方法及装置
WO2022134233A1 (zh) 一种区块链的共识方法、装置、服务器及存储介质
CN111949293A (zh) 固件升级方法、装置、计算机设备和存储介质
CN114503041B (zh) 车辆诊断方法、诊断连接器及诊断设备
CN116670636A (zh) 数据存取方法、装置和存储介质
CN111615819B (zh) 一种传输数据的方法和装置
CN112114938A (zh) 事务处理方法、装置及服务器
CN103685501A (zh) 数据处理方法、装置和系统
CN115396479B (zh) 机器人与云平台命令交互的方法、系统及存储介质
CN111198698B (zh) 基于EtherCAT的多设备固件程序并行下载方法及系统
CN114301812B (zh) 报文处理结果的监控方法、装置、设备以及存储介质
CN115422048A (zh) 链路稳定性测试方法、装置、计算机设备和存储介质
CN113626139B (zh) 一种高可用的虚拟机存储方法及装置
CN119402446B (zh) 一种网卡自动绑定方法、装置、设备、介质及程序产品
CN112596447B (zh) Ecu刷写数据长度的确定方法、装置、电子设备及介质
CN118862914A (zh) 扫码登录方法、装置、计算机设备及存储介质
CN118784526A (zh) 故障检测方法、报文传输方法、系统及客户端
CN112134749A (zh) 一种动态入网管理方法及系统
CN118075278A (zh) 数据传输方法、装置、设备及介质
CN111556043B (zh) 一种报文处理方法、装置、系统、设备及可读存储介质
CN116389357B (zh) 基于片上网络的空洞地址处理方法、装置、设备及介质
CN118450161B (zh) 一种直播视频数据存储服务的管理方法及系统
TR2024016886T2 (tr) Araç teşhi̇s yönlendi̇rme yöntemi̇, ci̇hazi, si̇stemi̇, araç ve bellek ortami

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 23902172

Country of ref document: EP

Kind code of ref document: A1

WWE Wipo information: entry into national phase

Ref document number: 2024/016886

Country of ref document: TR

WWE Wipo information: entry into national phase

Ref document number: 2023902172

Country of ref document: EP

NENP Non-entry into the national phase

Ref country code: DE

ENP Entry into the national phase

Ref document number: 2023902172

Country of ref document: EP

Effective date: 20250703

WWP Wipo information: published in national office

Ref document number: 2023902172

Country of ref document: EP