Vehicle diagnosis method and device, chip and vehicle

Abstract

The invention provides a vehicle diagnosis method and device, a chip, a vehicle, a computer readable storage medium and a computer program product. The method comprises the following steps: receiving a first hypertext transfer protocol HTTP request message sent by diagnosis equipment; wherein the first HTTP request message is used for requesting a target resource in the target node; the communication protocol used by the target node is a unified diagnostic service UDS communication protocol; the first HTTP request message is converted into a UDS request message, and the UDS request message is sent to a target node; receiving a UDS response message sent by the target node; wherein the UDS response message comprises resource information of a target resource in the target node; and converting the UDS response message into a first HTTP response message, and sending the first HTTP response message to the diagnostic device. According to the invention, the method can be better suitable for the whole vehicle topology which is high in HPC node occupation ratio and is added with Ethernet connection; and meanwhile, the node using the UDS communication protocol in the vehicle can be diagnosed.

Description

Technical Field

[0001] The present application relates to vehicle technology, and in particular to a vehicle diagnosis method, device, chip, vehicle, computer-readable storage medium, and computer program product. Background Art

[0002] Vehicle diagnosis refers to the use of professional diagnostic equipment to detect and analyze the electronic control unit (ECU) inside the vehicle to determine possible faults or problems in the vehicle. It aims to help vehicle maintenance technicians or car owners identify and solve problems with vehicle performance, safety or emissions.

[0003] In the field of vehicle diagnostic architecture design, the current common vehicle diagnostic architecture design scheme is based on Unified Diagnostic Services (UDS). Specifically, there is a central diagnostic gateway inside the vehicle, which receives UDS request messages from external diagnostic devices and then forwards the UDS request messages to the corresponding ECU. The current diagnostic architecture scheme is more suitable for the traditional vehicle topology based on microcontrollers (MCU) connected through the controller area network bus (CAN), but it is not very suitable for the vehicle topology with an increasing proportion of high-performance computer nodes and Ethernet connections. The traditional UDS protocol cannot diagnose vehicle faults well. Summary of the invention

[0004] The present application provides a vehicle diagnostic method, device, chip, vehicle, computer-readable storage medium and computer program product, which can be better applicable to the whole vehicle topology with a high proportion of HPC nodes and Ethernet connection.

[0005] The technical solution of this application is implemented as follows:

[0006] The present application provides a vehicle diagnosis method, which is applied to a master control node in a vehicle; the method comprises:

[0007] Receive a first Hypertext Transfer Protocol (HTTP) request message sent by a diagnostic device; wherein the first HTTP request message is used to request a target resource in a target node; and the communication protocol used by the target node is a unified diagnostic service (UDS) communication protocol;

[0008] Convert the first HTTP request message into a UDS request message, and send the UDS request message to the target node;

[0009] receiving a UDS response message sent by the target node; wherein the UDS response message includes resource information of the target resource in the target node;

[0010] The UDS response message is converted into a first HTTP response message, and the first HTTP response message is sent to the diagnostic device.

[0011] The present application provides a vehicle diagnostic device, which is applied to a master control node in a vehicle; the device comprises:

[0012] A first receiving module is used to receive a first Hypertext Transfer Protocol (HTTP) request message sent by a diagnostic device; wherein the first HTTP request message is used to request a target resource in a target node; and the communication protocol used by the target node is a unified diagnostic service (UDS) communication protocol;

[0013] A resource information acquisition module, used for converting the first HTTP request message into a UDS request message, and sending the UDS request message to the target node;

[0014] The resource information acquisition module is further used to receive a UDS response message sent by the target node; wherein the UDS response message includes resource information of the target resource in the target node;

[0015] The first sending module is used to convert the UDS response message into a first HTTP response message, and send the first HTTP response message to the diagnostic device.

[0016] The present application provides a chip, which includes executable instructions. The chip runs in a vehicle to implement the vehicle diagnostic method provided by the present application.

[0017] The present application provides a vehicle, comprising:

[0018] A memory for storing executable instructions;

[0019] The processor is used to implement the vehicle diagnosis method provided in the present application when executing the executable instructions stored in the memory.

[0020] The present application provides a computer-readable storage medium storing executable instructions for causing a processor to execute and implement the vehicle diagnostic method provided by the present application.

[0021] The present application provides a computer program product, which includes executable instructions for causing a processor to execute and implement the vehicle diagnosis method provided by the present application.

[0022] This application has the following beneficial effects:

[0023] The present application receives a first Hypertext Transfer Protocol (HTTP) request message sent by a diagnostic device; wherein the first HTTP request message is used to request a target resource in a target node; the communication protocol used by the target node is the Unified Diagnostic Service (UDS) communication protocol; the first HTTP request message is converted into a UDS request message, and the UDS request message is sent to the target node; a UDS response message is received from the target node; wherein the UDS response message includes resource information of the target resource in the target node; the UDS response message is converted into a first HTTP response message, and the first HTTP response message is sent to the diagnostic device. The present application treats the vehicle to be diagnosed as an HTTP server, and the diagnostic device obtains resource information in the form of direct access, which can more conveniently diagnose vehicles with HPC nodes; at the same time, it can diagnose nodes in the vehicle that use the UDS communication protocol, and has strong compatibility. BRIEF DESCRIPTION OF THE DRAWINGS

[0024] In order to more clearly illustrate the technical solutions in the embodiments of the present application, the drawings required for use in the description of the embodiments will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present application. For those skilled in the art, other drawings can be obtained based on these drawings without creative work.

[0025] Figure 1 is a first schematic diagram of the architecture of a vehicle diagnostic system provided in an embodiment of the present application;

[0026] Figure 2 is a structural schematic diagram of a vehicle provided in an embodiment of the present application;

[0027] Figure 3A is a first flow chart of a vehicle diagnostic method provided by an embodiment of the present application;

[0028] Figure 3B is a second flow chart of the vehicle diagnostic method provided by an embodiment of the present application;

[0029] Figure 4 is a second schematic diagram of the architecture of the vehicle diagnostic system provided in an embodiment of the present application;

[0030] Figure 5 It is a structural diagram of an HPC master control node provided in an embodiment of the present application;

[0031] Figure 6 It is a flowchart of message conversion provided in an embodiment of the present application. DETAILED DESCRIPTION

[0032] In order to make the purpose, technical solutions and advantages of the present application clearer, the present application will be further described in detail below in conjunction with the accompanying drawings. The described embodiments should not be regarded as limiting the present application. All other embodiments obtained by ordinary technicians in the field without making creative work are within the scope of protection of this application.

[0033] In the following description, reference is made to "some embodiments", which describes a subset of all possible embodiments, but it is understood that "some embodiments" may be the same subset or different subsets of all possible embodiments, and may be combined with each other without conflict. In the following description, reference is made to the term "multiple" to mean at least two.

[0034] In the following description, the terms "first\second\third" involved are merely used to distinguish similar objects and do not represent a specific ordering of the objects. It can be understood that "first\second\third" can be interchanged with a specific order or sequence where permitted, so that the embodiments of the present application described herein can be implemented in an order other than that illustrated or described herein.

[0035] Unless otherwise defined, all technical and scientific terms used herein have the same meaning as those commonly understood by those skilled in the art to which this application belongs. The terms used herein are only for the purpose of describing the embodiments of this application and are not intended to limit this application.

[0036] The embodiments of the present application provide a vehicle diagnostic method, device, chip, vehicle, computer-readable storage medium, and computer program product, which can be better adapted to a vehicle topology in which a high proportion of HPC nodes are present and Ethernet connections are added.

[0037] See also Figure 1 , Figure 1 1 is a schematic diagram of the architecture of the vehicle diagnostic system 100 provided in the embodiment of the present application. The diagnostic device 400 is connected to the node 200-1 (i.e., the master node) in the vehicle 200 via the network 300. Figure 1 Also shown are nodes 200 - 2 and 200 - 3 which are different from the node 200 - 1 , wherein the network 300 may be a wide area network or a local area network, or a combination of the two.

[0038] In some embodiments, the diagnostic device 400 sends a first HyperText Transfer Protocol (HTTP) request message to the node 200-1, wherein the first HTTP request message is used to request the target resource in the target node, and the target node may be any one of the nodes 200-1, 200-2, and 200-3; the node 200-1 obtains the resource information of the target resource in the target node through the target communication protocol, wherein the target communication protocol represents the communication protocol used by the target node; the node 200-1 sends a first HTTP response message to the diagnostic device 400, and the first HTTP response message includes the resource information of the target resource in the target node; the diagnostic device 400 obtains the resource information of the target resource in the target node from the first HTTP response message, and displays the resource information of the target resource in the target node for the convenience of relevant personnel (such as vehicle maintenance technicians or car owners) to view.

[0039] In some embodiments, the diagnostic device 400 and the node 200 - 1 may be directly or indirectly connected via wired or wireless communication, which is not limited in the embodiments of the present application.

[0040] See also Figure 2 , Figure 2 is a schematic diagram of the structure of a vehicle 200 provided in an embodiment of the present application, Figure 2 The vehicle 200 shown includes: at least one processor 210, a memory 250, at least one network interface 220 and a user interface 230. The various components in the vehicle 200 are coupled together via a bus system 240. It is understood that the bus system 240 is used to achieve connection and communication between these components. Figure 2 Various buses are labeled as bus system 240 .

[0041] The processor 210 can be an integrated circuit chip with signal processing capabilities, such as a general-purpose processor, a digital signal processor (DSP), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc., where the general-purpose processor can be a microprocessor or any conventional processor, etc.

[0042] The user interface 230 includes one or more output devices 231 that enable presentation of media content, including one or more speakers and / or one or more visual display screens. The user interface 230 also includes one or more input devices 232, including user interface components that facilitate user input, such as microphones, touch screen displays, cameras, other input buttons and controls.

[0043] The memory 250 may be removable, non-removable, or a combination thereof. Exemplary hardware devices include solid-state memory, hard disk drives, optical disk drives, etc. The memory 250 may optionally include one or more storage devices that are physically remote from the processor 210.

[0044] The memory 250 includes a volatile memory or a non-volatile memory, and may also include both volatile and non-volatile memories. The non-volatile memory may be a read-only memory (ROM), and the volatile memory may be a random access memory (RAM). The memory 250 described in the embodiment of the present application is intended to include any suitable type of memory.

[0045] In some embodiments, memory 250 can store data to support various operations, examples of which include programs, modules, and data structures, or a subset or superset thereof, as exemplarily described below.

[0046] Operating system 251, including system programs for processing various basic system services and performing hardware-related tasks, such as a framework layer, a core library layer, a driver layer, etc., for implementing various basic services and processing hardware-based tasks;

[0047] A network communication module 252, used to reach other electronic devices via one or more (wired or wireless) network interfaces 220, exemplary network interfaces 220 include: Bluetooth, Wireless Compatibility Certification (WiFi), and Universal Serial Bus (USB), etc.;

[0048] a presentation module 253 for enabling presentation of information via one or more output devices 231 (e.g., display screen, speaker, etc.) associated with the user interface 230 (e.g., a user interface for operating peripherals and displaying content and information);

[0049] The input processing module 254 is used to detect one or more user inputs or interactions from one of the one or more input devices 232 and translate the detected inputs or interactions.

[0050] In some embodiments, the vehicle diagnostic device provided in the embodiments of the present application can be implemented in software. Figure 2The vehicle diagnostic device 255 stored in the memory 250 is shown, which can be software in the form of a program and a plug-in, etc., and includes the following software modules: a first receiving module 2551, a resource information acquisition module 2552, and a first sending module 2553. These modules are logical, and therefore can be arbitrarily combined or further split according to the functions implemented. The functions of each module will be described below.

[0051] See also Figure 3A , Figure 3A is a flow chart of a vehicle diagnostic method provided by an embodiment of the present application, which will be combined with Figure 3A The steps shown are explained.

[0052] In step 101, a first Hypertext Transfer Protocol (HTTP) request message sent by a diagnostic device is received; wherein the first HTTP request message is used to request a target resource in a target node; and the communication protocol used by the target node is the Unified Diagnostic Service (UDS) communication protocol.

[0053] Here, the main control node in the vehicle receives the first HTTP request message sent by the diagnostic device, and parses the first HTTP request message, thereby knowing that the first HTTP request message is used to request the target resource in the target node.

[0054] It is worth noting that the node involved in the embodiment of the present application refers to the ECU inside the vehicle.

[0055] It is worth noting that the communication protocol used by the master control node is HTTP, for example, the master control node can be an HPC node; the vehicle includes at least one node using HTTP, one of which can be pre-configured as the master control node, for example, one of multiple HPC nodes can be pre-configured as the master control node.

[0056] It is worth noting that the communication protocol used by the target node can be determined according to the type of the target node. For example, the communication protocol used by the HPC node is HTTP, and the communication protocol used by the MCU node is UDS.

[0057] In some embodiments, before receiving the first hypertext transfer protocol HTTP request message sent by the diagnostic device, the vehicle diagnostic method further includes: establishing an HTTP communication connection with the diagnostic device. Here, the HTTP communication connection between the master control node and the diagnostic device can be a wired connection or a wireless connection (such as a 4G / 5G wireless connection).

[0058] In some embodiments, the target node is any one of a master node, a first node, and a second node. The first node refers to a node using the UDS communication protocol, and the second node refers to a node using HTTP and different from the master node. Figure 3A The case where the target node is the first node is taken as an example for description.

[0059] In step 102, the first HTTP request message is converted into a UDS request message, and the UDS request message is sent to the target node.

[0060] Since the target node is the first node (such as an MCU node) using the UDS communication protocol, in this case, since the target node does not support HTTP, the master control node converts the first HTTP request message into a UDS request message and sends the UDS request message to the target node.

[0061] In step 103, a UDS response message sent by the target node is received; wherein the UDS response message includes resource information of the target resource in the target node.

[0062] The target node parses the received UDS request message, and learns that the UDS request message is used to request the target resource in the target node. Therefore, the target node obtains the resource information of the target resource in the target node, generates a UDS response message according to the resource information of the target resource in the target node, and sends the UDS response message to the master control node.

[0063] It is worth noting that the resources involved in the embodiments of the present application refer to resource items (or resource types) that support diagnosis in the node, such as data resources (such as configuration, system power supply voltage, faults, etc.), log resources, etc.; resource information refers to the specific information of the resources, such as specific configuration information, voltage values, fault information, etc.

[0064] In step 104, the UDS response message is converted into a first HTTP response message, and the first HTTP response message is sent to the diagnostic device.

[0065] Here, when receiving the UDS response message, the main control node converts the UDS response message into a first HTTP response message, and sends the first HTTP response message to the diagnostic device.

[0066] Among them, converting the UDS response message into the first HTTP response message may mean that the payload remains unchanged, that is, it only involves repackaging at the protocol level; or, considering that the signal value of the UDS communication protocol is not easy to read, converting the UDS response message into the first HTTP response message may also mean a change in the payload and repackaging at the protocol level. The change in payload refers to changing the representation of the resource information of the target resource in the target node from a signal value to a physical value. In this way, the readability of the information displayed by the subsequent diagnostic equipment can be improved, and the operational threshold for vehicle diagnosis can be lowered.

[0067] When receiving the first HTTP response message, the diagnostic device can obtain resource information of the target resource in the target node and display it, so as to facilitate relevant personnel to locate the vehicle fault.

[0068] In some embodiments, the above-mentioned conversion of the first HTTP request message into the UDS request message can be achieved in the following manner: the first HTTP request message is converted into the UDS request message according to a conversion configuration file; wherein the conversion configuration file includes a conversion relationship between a physical value and a signal value of the UDS communication protocol; the above-mentioned conversion of the UDS response message into the first HTTP response message can be achieved in the following manner: the UDS response message is converted into the first HTTP response message according to the conversion configuration file.

[0069] Here, the master control node implements the conversion from the first HTTP request message to the UDS request message according to a pre-stored conversion configuration file, wherein the conversion configuration file includes the conversion relationship between the physical value and the signal value of the UDS communication protocol, and the conversion configuration file is used to realize the change of the load in the above-mentioned conversion process. Similarly, the master control node can implement the conversion from the UDS response message to the first HTTP response message according to the conversion configuration file. In the above manner, the accuracy of the message conversion can be improved and the accurate conversion between the physical value and the signal value can be ensured. In some embodiments, the conversion configuration file can be bound to the target node, that is, the conversion configuration file corresponding to the target node includes the conversion relationship between the physical value and the signal value that the target node can use.

[0070] In some embodiments, the target node is a second node that uses HTTP and is different from the main control node; after receiving a first Hypertext Transfer Protocol HTTP request message sent by the diagnostic device, the vehicle diagnostic method also includes: sending the first HTTP request message to the target node; receiving an HTTP response message sent by the target node; wherein the HTTP response message sent by the target node includes resource information of a target resource in the target node; and sending the HTTP response message sent by the target node to the diagnostic device.

[0071] Here, the target node is a second node (such as other HPC nodes) that uses HTTP and is different from the master node. In this case, since the target node itself supports HTTP, the master node can send (route) the first HTTP request message to the target node, so that the target node obtains the resource information of the target resource in the target node, and then generates an HTTP response message based on the resource information of the target resource in the target node and sends it to the master node. Based on this, the master node can directly forward the HTTP response message sent by the target node to the diagnostic device. In the above method, the master node is mainly used to realize the transfer function, and can accurately route the request initiated by the diagnostic device to the corresponding node.

[0072] In some embodiments, the target node is a main control node; after receiving a first Hypertext Transfer Protocol HTTP request message sent by a diagnostic device, the vehicle diagnostic method also includes: initiating a request to a software component in the target node through a private communication protocol to obtain resource information of the target resource in the software component; generating an HTTP response message based on the resource information of the target resource in the software component, and sending the HTTP response message to the diagnostic device.

[0073] Here, the target node is the master control node itself. In this case, the master control node initiates a request to the software component (SWC) in the master control node through a private communication protocol to obtain the resource information of the target resource in the software component, wherein the private communication protocol refers to the communication protocol used by the software component. Then, the master control node generates an HTTP response message according to the resource information of the target resource in its own software component (that is, the resource information of the target resource in the software component is encapsulated as an HTTP response message), and sends the HTTP response message to the diagnostic device. In this way, accurate resource information can be collected from the software component of the master control node itself.

[0074] It is worth noting that the software component here refers to a software component that has a target resource. For example, if the target resource is a log resource, the software component is a data logging tool (Data Log Tool, DLT) component.

[0075] It is worth noting that the way in which the master node obtains its own resource information can also be applied to other nodes.

[0076] like Figure 3A As shown, the embodiment of the present application receives a first Hypertext Transfer Protocol HTTP request message sent by a diagnostic device; wherein the first HTTP request message is used to request a target resource in a target node; the communication protocol used by the target node is the Unified Diagnostic Service UDS communication protocol; the first HTTP request message is converted into a UDS request message, and the UDS request message is sent to the target node; a UDS response message is received from the target node; wherein the UDS response message includes resource information of the target resource in the target node; the UDS response message is converted into a first HTTP response message, and the first HTTP response message is sent to the diagnostic device. The embodiment of the present application treats the vehicle to be diagnosed as an HTTP server, and the diagnostic device obtains resource information in the form of direct access, which can more conveniently diagnose vehicles with HPC nodes; at the same time, it can diagnose nodes in the vehicle that use the UDS communication protocol, and has strong compatibility.

[0077] In some embodiments, see Figure 3B , Figure 3Bis a flow chart of a vehicle diagnostic method provided by an embodiment of the present application, Figure 3A Steps 301 to 304 may be performed before step 101 shown.

[0078] In step 301, a second HTTP request message sent by a diagnostic device is received; wherein the second HTTP request message is used to request a diagnosable node in a vehicle.

[0079] Here, the main control node receives the second HTTP request message sent by the diagnostic device, and parses the second HTTP request message, thereby knowing that the second HTTP request message is used to request a diagnosable node in the vehicle, where a diagnosable node refers to a node that supports diagnosis, and the same applies to subsequent diagnosable resources.

[0080] In step 302, a second HTTP response message is generated according to the diagnosable node in the vehicle, and the second HTTP response message is sent to the diagnostic device.

[0081] Here, the master control node determines the diagnosable nodes in the vehicle, wherein the diagnosable nodes in the vehicle may be predetermined; or, the master control node may also determine the diagnosable nodes in the vehicle in real time. Then, the master control node generates a second HTTP response message based on the diagnosable nodes in the vehicle, and sends the second HTTP response message to the diagnostic device. For example, the master control node may encapsulate the identification information (such as the name) related to the diagnosable nodes in the vehicle into the second HTTP response message. The diagnostic device determines the target node based on the diagnosable nodes in the vehicle, and generates a third HTTP request message, that is, the third HTTP request message is generated by the diagnostic device based on the second HTTP response message. For example, the number of diagnosable nodes in the vehicle includes multiple nodes. When receiving the second HTTP response message, the diagnostic device may display multiple diagnosable nodes. In response to the selection operation for the displayed multiple diagnosable nodes, the selected diagnosable node is determined as the target node, and a third HTTP request message is generated.

[0082] In some embodiments, before generating the second HTTP response message according to the diagnosable nodes in the vehicle, the vehicle diagnosis method further includes: determining the diagnosable nodes in the vehicle according to a node list file corresponding to the vehicle.

[0083] Here, the vehicle has a node list file corresponding to the vehicle stored locally in advance. Based on this, the master control node can determine the diagnosable nodes in the vehicle according to the node list file corresponding to the vehicle. For example, the node list file corresponding to the vehicle is used to represent various diagnosable nodes that the vehicle may have, and the nodes represented by the node list file corresponding to the vehicle and actually possessed by the vehicle can be determined as the diagnosable nodes of the vehicle. In the above manner, it is ensured that the diagnosable nodes in the vehicle actually exist and support diagnosis.

[0084] In some embodiments, the above-mentioned determination of diagnosable nodes in a vehicle based on a node list file corresponding to the vehicle can be achieved in the following manner: reading node codes of multiple nodes in the vehicle; matching the node codes of multiple nodes in the vehicle with the node codes of multiple nodes in the node list file, and determining the nodes corresponding to the successfully matched node codes as diagnosable nodes in the vehicle.

[0085] Here, the node list file includes the node codes (or node identifiers) of multiple nodes (diagnosable nodes). Based on this, the master control node can read the node codes of multiple nodes in the vehicle and match the node codes of multiple nodes in the vehicle with the node codes of multiple nodes in the node list file. For example, if the node code of node A in the vehicle successfully matches (i.e., is the same as) a certain node code in the node list file, node A is determined as a diagnosable node in the vehicle. In this way, it is ensured that the diagnosable nodes in the vehicle actually exist and support diagnosis.

[0086] In step 303, a third HTTP request message sent by the diagnostic device is received; wherein the third HTTP request message is generated by the diagnostic device according to the second HTTP response message, and the third HTTP request message is used to request diagnosable resources in the target node.

[0087] Here, the main control node receives the third HTTP request message sent by the diagnostic device, and parses the third HTTP request message, thereby knowing that the third HTTP request message is used to request a diagnosable resource in the target node.

[0088] In step 304, a third HTTP response message is generated according to the diagnosable resources in the target node, and the third HTTP response message is sent to the diagnostic device; wherein the diagnostic device is used to generate a first HTTP request message according to the third HTTP response message.

[0089] Here, the master control node determines the diagnosable resources in the target node, wherein the diagnosable resources in the target node may be predetermined; or, the master control node may also determine the diagnosable resources in the target node in real time. Then, the master control node generates a third HTTP response message according to the diagnosable resources in the target node, and sends the third HTTP response message to the diagnostic device. For example, the master control node may encapsulate the identification information (such as the name) related to the diagnosable resources in the target node into the third HTTP response message. The diagnostic device determines the target resource according to the diagnosable resources in the target node, and generates a first HTTP request message. For example, the diagnosable resources in the target node include multiple types. When the diagnostic device receives the third HTTP response message, it may display multiple diagnosable resources. In response to the selection operation for the displayed multiple diagnosable resources, the selected diagnosable resource is determined as the target resource, and a first HTTP request message is generated.

[0090] In some embodiments, before generating the third HTTP response message according to the diagnosable resources in the target node, the vehicle diagnosis method further includes: determining the diagnosable resources in the target node according to a resource list file corresponding to the target node.

[0091] Here, the vehicle locally stores resource list files corresponding to multiple nodes respectively. Based on this, the master control node can determine the diagnosable resources represented by the resource list file corresponding to the target node as the diagnosable resources in the target node. In this way, it is ensured that the diagnosable resources in the target node actually exist and support diagnosis.

[0092] In some embodiments, the resource list file corresponding to the target node includes a data resource list file and a log resource list file; the above-mentioned determination of the diagnosable resources in the target node based on the resource list file corresponding to the target node can be achieved in the following manner: when the third HTTP request message is used to request the diagnosable data resources in the target node, the data resource list file corresponding to the target node is queried and processed to obtain the diagnosable data resources in the target node; when the third HTTP request message is used to request the diagnosable log resources in the target node, the log resource list file corresponding to the target node is queried and processed to obtain the diagnosable log resources in the target node.

[0093] Here, the diagnostic device can request the diagnosable data resources or diagnosable log resources in the target node. For the former case, the main control node queries and processes the data resource list file corresponding to the target node to obtain the diagnosable data resources in the target node; for the latter case, the main control node queries and processes the log resource list file corresponding to the target node to obtain the diagnosable log resources in the target node. Through the above method, the pertinence of vehicle diagnosis can be improved, that is, it can support vehicle diagnosis according to actual needs. Of course, in some embodiments, the diagnostic device can also request all diagnosable resources in the target node (including diagnosable data resources and diagnosable log resources).

[0094] like Figure 3B As shown, the embodiment of the present application receives a second HTTP request message sent by a diagnostic device; wherein the second HTTP request message is used to request a diagnosable node in a vehicle; a second HTTP response message is generated according to the diagnosable node in the vehicle, and the second HTTP response message is sent to the diagnostic device; a third HTTP request message is received from the diagnostic device; wherein the third HTTP request message is used to request a diagnosable resource in a target node; a third HTTP response message is generated according to the diagnosable resource in the target node, and the third HTTP response message is sent to the diagnostic device; wherein the diagnostic device is used to generate a first HTTP request message according to the third HTTP response message. In this way, first, the diagnosable node in the vehicle is notified to the diagnostic device in the form of HTTP, and after the diagnostic device is determined as a target node, the diagnosable resource in the target node is notified to the diagnostic device in the form of HTTP, so that the diagnostic device generates a first HTTP request message.

[0095] Below, an exemplary application of the embodiment of the present application in a practical application scenario will be described. As an example, the embodiment of the present application provides the following Figure 4 A schematic diagram of the vehicle diagnostic system shown in FIG. Figure 4 In the embodiment, the diagnostic device establishes an HTTP communication connection with the HTTP server deployed inside the HPC master control node (corresponding to the master control node above) in the vehicle. The HTTP server integrates an HTTP Wrapper library (HTTP packaging library) inside, which can process HTTP request messages and HTTP response messages. The diagnostic device can be regarded as an HTTP client. At the same time, the HPC master control node also has a conversion module (or HTTP Server Adapter To UDS module) deployed inside to realize the conversion between HTTP messages and UDS messages, so that the embodiment of the present application can be compatible with the whole vehicle architecture including traditional MCU nodes at the same time. In addition, the embodiment of the present application also provides such Figure 5 The structure diagram of the HPC master node is shown in Figure 1. Figure 4 as well as Figure 5 , explained in step form.

[0096] Step 1) The diagnostic device establishes an HTTP communication connection with the HPC master control node (HTTP server in the HPC master control node).

[0097] The HTTP communication connection can be a wired connection, such as a wired connection based on a physical network cable, or a wireless connection, such as a wireless connection based on 4G / 5G. For the sake of convenience, the IP address of the HPC master node exposed to the outside is 10.1.0.79.

[0098] Step 2) The diagnostic device uses the HTTP get method to request the diagnostic service supported by the vehicle.

[0099] Based on the established HTTP communication connection, the diagnostic device can interact with the HPC master node through commonly used HTTP put / get / post methods. In the embodiment of the present application, the diagnostic device mainly uses the get method to initiate an HTTP request message, and the request content exists in the form of a uniform resource locator (URL).

[0100] For example, the HTTP vehicle-cloud interaction protocol is defined as shown in Table 1:

[0101] Table 1 HTTP vehicle-cloud interaction protocol

[0102]

[0103]

[0104] It is worth noting that the entities field in the URL address determines to which node the HTTP request message is ultimately routed, and the data field indicates the type of resource to be requested.

[0105] Based on the above vehicle-cloud interaction protocol, the diagnostic device first uses the HTTP get method to request the diagnosable nodes in the vehicle. The request link in the HTTP request message is https: / / 10.1.0.79 / entities. When the HPC master node receives the HTTP request message, it parses the Project_ODX_List.json file (corresponding to the node list file above), matches the LAS code actually read by the vehicle (corresponding to the node code above), and returns the ECUName and Chinese Name of the diagnosable nodes actually contained in the vehicle.

[0106] Among them, the Project_ODX_List.json file example is as follows:

[0107]

[0108] After receiving the names of multiple diagnosable nodes in the vehicle, the diagnostic device can display them in the front-end interface of the diagnostic device. Then, in response to the selection operation for the displayed multiple diagnosable nodes (names of diagnosable nodes), the selected diagnosable node is determined as the target node, and the HTTP get method is used to request the diagnosable resources in the target node. In the embodiment of the present application, the diagnosable resources may include two parts. The first part comes from the ODX.json file of each ECU (corresponding to the data resource list file above). By parsing the SHORT-NAME field in the ODX.json file, the diagnosable data resources that the ECU supports access to can be obtained; the other part comes from the DLT.json file of each ECU (corresponding to the log resource list file above). By parsing the DLT field in the DLT.json file, the APPID of the diagnosable log resources that the ECU supports access to can be obtained.

[0109] The following is an example of an ODX.json file:

[0110] {

[0111] "SHORT-NAME":"Power Voltage Read",

[0112] "LONG-NAME":"Power Voltage Read",

[0113] "SEMANTIC":"MEASUREMENT-VALUES-READ",

[0114] "DESC":"System power supply voltage",

[0115] "SEND":"221000",

[0116] "POSRESPONSE":"621000",

[0117] "NEGRESPONSE":"7E22",

[0118] …

[0119] }

[0120] The following is an example of a DLT.json file:

[0121]

[0122] The diagnostic device uses the HTTP get method to request at least one of the diagnosable data resources and diagnosable log resources in the target node. Taking the case where the diagnostic device simultaneously requests the diagnosable data resources and the diagnosable log resources, the HPC master control node responds to the request, queries the ODX.json file to obtain the diagnosable data resources in the target node, queries the DLT.json file to obtain the diagnosable log resources in the target node, and returns the diagnosable data resources and diagnosable log resources in the target node to the diagnostic device in the form of an HTTP response message.

[0123] Step 3) The diagnostic device uses the HTTP get method to request the target resource in the target node.

[0124] The diagnostic device can display the diagnosable resources in the target node by means of a drop-down menu, and then, in response to the selection operation for the displayed diagnosable resources, the selected diagnosable resources are determined as target resources, and an HTTP request message is generated and sent to the HPC master control node, and the HTTP request message is used to request the target resource in the target node. For example, the user clicks on the CCU part (i.e., the HPC master control node) in the front-end interface of the diagnostic device, enters the sub-interface and selects "System Power Supply Voltage" in the drop-down menu, then the diagnostic device sends an HTTP request message of get https: / / 10.1.0.79 / CCU / Power_Voltage_Read to the HPC master control node.

[0125] When receiving the HTTP request message (ie, the first HTTP request message), the HTTP server in the HPC master control node parses the URL address therein and performs corresponding operations according to the parsed target node, which will be explained separately below.

[0126] ① The target node is the MCU node (corresponding to the first node above).

[0127] The data type in the UDS response message of the traditional MCU node is HEX data stream (that is, represented by signal value). In order to enable the HPC master control node to return the real physical value to the outside, it is necessary to deploy the Open Diagnostic Data eXchange (ODX) file inside the HTTP Server Adapter To UDS module to parse the HEX data stream responded by the MCU node into physical values ​​and then return it to the HPC master control node.

[0128] For example, when the HTTP server in the HPC master node parses the HTTP request message and finds that the target node requested is an MCU node, it transmits the ECU and ServiceShortName (name of the target resource) in the HTTP request message to the HTTP Server Adapter To UDS module, which calls the conversion function (CallOdxServiceByShortName function), parses the internal preset ODX file, converts it into a signal value and sends it to the MCU node. Similarly, the HTTP Server AdapterTo UDS module converts the signal value returned by the MCU node into a physical value and transmits the physical value to the HTTP server, so that the HTTP server returns it to the diagnostic device through HTTP.

[0129] Examples of conversion functions are as follows:

[0130] [int Result, object PositiveResponseParam, string NegativeResponseParam, vciResult VciResult] = CallOdxServiceByShortName (ecuDtObj ECU, stringServiceShortName)

[0131] The input parameters of the conversion function are shown in Table 2:

[0132] Table 2 Input parameter description

[0133]

[0134] The output parameters of the conversion function are shown in Table 3:

[0135] Table 3 Output parameter description

[0136]

[0137]

[0138] For example, when the URL address in the HTTP request message is https: / / 10.1.0.79 / CCU / Power_Voltage_Read, the HTTP server can parse the ECU as CCU and the ServiceShortName as Power_Voltage_Read. The HTTP Server Adapter To UDS module can convert this information into a UDS request message of 74F 22 1000.

[0139] For example, Figure 6 As shown in the figure, the HTTP request message is GET https: / / Hpc.io / components / DrivingComputer / data / Location. After conversion by the HTTP Server Adapter To UDS module, a UDS request message of 0x22 12 34 can be obtained. If the UDS response message is 0x62 12 34 56 78, after conversion by the HTTP ServerAdapter To UDS module, an HTTP response message can be obtained, which is as follows:

[0140]

[0141] It is worth mentioning that the HTTP Server Adapter To UDS module needs to rely on ODX files to realize the conversion between HTTP messages and UDS messages. The ODX files of all ECUs form a PDX file, which is regularly sent from the cloud to the vehicle for update to ensure the real-time nature of the PDX file, thereby ensuring the accurate conversion between HTTP messages and UDS messages.

[0142] ②The target node is the HPC master node.

[0143] If the target node is the HPC master node itself, the HTTP server in the HPC master node obtains resource information from the internal software components through a private communication protocol, generates an HTTP response message, and sends it to the diagnostic device. Figure 5 In the example, the HPC master control node obtains resource information from software component 1, software component 2, and software component 3 through a private communication protocol, wherein the types of software components are not limited, such as a platform health management module (PHM) component, a DLT component, and the like.

[0144] ③The target node is the HPC slave node (corresponding to the second node above).

[0145] Here, the HPC slave node refers to an HPC node different from the HPC master node. If the target node is an HPC slave node, the HTTP server in the HPC master node directly communicates with the HTTP server of the HPC slave node through HTTP to obtain resource information of the target resource in the HPC slave node, and then generates an HTTP response message and sends it to the diagnostic device.

[0146] For the sake of illustration, some examples of HTTP request messages and HTTP response messages are given below:

[0147] 1) Request a diagnosable node in the vehicle.

[0148] Request:

[0149] GET https: / / 10.1.0.79 / entities HTTP / 1.1Response:

[0150] HTTP / 1.1 200OK

[0151] {

[0152] "items":[

[0153] {

[0154] "id":"CCU",

[0155] "name":"Central Control Unit",

[0156] "href":"{base_uri} / entities / CCU"

[0157] },

[0158] {

[0159] "id":"ZCUR",

[0160] "name":"Right Area Controller",

[0161] "href":"{base_uri} / entities / ZCUR"

[0162] },

[0163] {

[0164] "id":"ZCUL",

[0165] "name":"Left Area Controller",

[0166] "href":"{base_uri} / entities / ZCUL"

[0167] } ]

[0169] }

[0170] 2) Request the battery voltage in the CCU.

[0171] Request:

[0172] GET https: / / 10.1.0.79 / CCU / Power_Voltage_Read Response:

[0173] HTTP / 1.1 200OK

[0174] {

[0175] {

[0176] "ECU":"CCU",

[0177] "ServiceShortName":"Power_Voltage_Read","data":

[0178] {

[0179] "Battery voltage": "13.4V"

[0180] }

[0181] } ]

[0183] }

[0184] The embodiments of the present application have at least the following technical effects:

[0185] 1) Treat the vehicle being diagnosed as an HTTP server and obtain resource information in the form of direct access, which makes it easier to diagnose the vehicle architecture with HPC nodes.

[0186] 2) The vehicle information that can be obtained is richer. In addition to the traditional UDS configuration information, it can also obtain application log information and controller resource usage information, such as CPU load, RAM load, etc.

[0187] 3) The embodiment of the present application additionally adds an HTTP Server Adapter To UDS module, so that the HTTP protocol can be converted to and from the UDS protocol, and the signal value is converted into a real physical value, thereby providing the physical value to the external diagnostic device without the need for further analysis by the diagnostic device, which makes it more convenient to design the web application in the diagnostic device. At the same time, the physical value is easier to read and understand, making it easier for relevant personnel to locate vehicle faults.

[0188] The following is a description of an exemplary structure of the vehicle diagnostic device 255 provided in the embodiment of the present application implemented as a software module. In some embodiments, Figure 2As shown, the software modules stored in the vehicle diagnostic device 255 of the memory 250 may include: a first receiving module 2551, used to receive a first hypertext transfer protocol HTTP request message sent by the diagnostic device; wherein the first HTTP request message is used to request a target resource in a target node; the communication protocol used by the target node is a unified diagnostic service UDS communication protocol; a resource information acquisition module 2552, used to convert the first HTTP request message into a UDS request message, and send the UDS request message to the target node; the resource information acquisition module 2552, is also used to receive a UDS response message sent by the target node; wherein the UDS response message includes resource information of the target resource in the target node; a first sending module 2553, used to convert the UDS response message into a first HTTP response message, and send the first HTTP response message to the diagnostic device.

[0189] In some embodiments, the resource information acquisition module 2552 is also used to: convert the first HTTP request message into a UDS request message according to a conversion configuration file; wherein the conversion configuration file includes a conversion relationship between physical values ​​and signal values ​​of the UDS communication protocol; and convert the UDS response message into a first HTTP response message according to the conversion configuration file.

[0190] In some embodiments, the vehicle diagnostic device 255 also includes a second receiving module for receiving a second HTTP request message sent by the diagnostic device; wherein the second HTTP request message is used to request a diagnosable node in the vehicle; the vehicle diagnostic device 255 also includes a second sending module for generating a second HTTP response message based on the diagnosable node in the vehicle, and sending the second HTTP response message to the diagnostic device; the vehicle diagnostic device 255 also includes a third receiving module for receiving a third HTTP request message sent by the diagnostic device; wherein the third HTTP request message is generated by the diagnostic device based on the second HTTP response message, and the third HTTP request message is used to request a diagnosable resource in the target node; the vehicle diagnostic device 255 also includes a third sending module for generating a third HTTP response message based on the diagnosable resource in the target node, and sending the third HTTP response message to the diagnostic device; wherein the diagnostic device is used to generate a first HTTP request message based on the third HTTP response message.

[0191] In some embodiments, the second sending module is further used to determine the diagnosable nodes in the vehicle according to the node list file corresponding to the vehicle; the third sending module is further used to determine the diagnosable resources in the target node according to the resource list file corresponding to the target node.

[0192] In some embodiments, the second sending module is also used to: read the node codes of multiple nodes in the vehicle; match the node codes of multiple nodes in the vehicle with the node codes of multiple nodes in the node list file, and determine the nodes corresponding to the successfully matched node codes as diagnosable nodes in the vehicle.

[0193] In some embodiments, the resource list file corresponding to the target node includes a data resource list file and a log resource list file; the third sending module is also used to: when the third HTTP request message is used to request the diagnosable data resources in the target node, query and process the data resource list file corresponding to the target node to obtain the diagnosable data resources in the target node; when the third HTTP request message is used to request the diagnosable log resources in the target node, query and process the log resource list file corresponding to the target node to obtain the diagnosable log resources in the target node.

[0194] The present application provides a chip, the chip includes executable instructions, and the chip runs in a vehicle to implement the vehicle diagnosis method provided by the present application. In some embodiments, the chip may refer to a chip in a master control node.

[0195] The embodiment of the present application provides a computer program product or a computer program, which includes executable instructions stored in a computer-readable storage medium. The processor of the vehicle reads the executable instructions from the computer-readable storage medium, and the processor executes the executable instructions, so that the vehicle implements the vehicle diagnostic method described in the embodiment of the present application.

[0196] An embodiment of the present application provides a computer-readable storage medium storing executable instructions, wherein executable instructions are stored. When the executable instructions are executed by a processor, the processor will implement the vehicle diagnostic method provided by the embodiment of the present application.

[0197] In some embodiments, the computer-readable storage medium may be a memory such as FRAM, ROM, PROM, EPROM, EEPROM, flash memory, magnetic surface storage, optical disk, or CD-ROM; or it may be various devices including one or any combination of the above memories.

[0198] In some embodiments, executable instructions may be in the form of a program, software, software module, script or code, written in any form of programming language (including compiled or interpreted languages, or declarative or procedural languages), and may be deployed in any form, including as a stand-alone program or as a module, component, subroutine or other unit suitable for use in a computing environment.

[0199] As an example, executable instructions may, but need not, correspond to a file in a file system, may be stored as part of a file that stores other programs or data, such as in one or more scripts in a HyperText Markup Language (HTML) document, in a single file dedicated to the program in question, or in multiple coordinated files (e.g., files storing one or more modules, subroutines, or code portions).

[0200] The above are only embodiments of the present application and are not intended to limit the protection scope of the present application. Any modifications, equivalent substitutions and improvements made within the spirit and scope of the present application are included in the protection scope of the present application.

Claims

1. A vehicle diagnostic method, characterized in that: A master control node applied to a vehicle; the method comprises: Receive a first Hypertext Transfer Protocol (HTTP) request message sent by a diagnostic device; wherein the first HTTP request message is used to request a target resource in a target node; and the communication protocol used by the target node is a unified diagnostic service (UDS) communication protocol; Convert the first HTTP request message into a UDS request message, and send the UDS request message to the target node; receiving a UDS response message sent by the target node; wherein the UDS response message includes resource information of the target resource in the target node; The UDS response message is converted into a first HTTP response message, and the first HTTP response message is sent to the diagnostic device.

2. The method according to claim 1, characterized in that: The converting the first HTTP request message into a UDS request message includes: Converting the first HTTP request message into a UDS request message according to a conversion configuration file; wherein the conversion configuration file includes a conversion relationship between a physical value and a signal value of a UDS communication protocol; The converting the UDS response message into a first HTTP response message includes: The UDS response message is converted into a first HTTP response message according to the conversion configuration file.

3. The method according to claim 1, characterized in that Before receiving the first Hypertext Transfer Protocol (HTTP) request message sent by the diagnostic device, the method further includes: Receiving a second HTTP request message sent by the diagnostic device; wherein the second HTTP request message is used to request a diagnosable node in the vehicle; generating a second HTTP response message according to the diagnosable node in the vehicle, and sending the second HTTP response message to the diagnostic device; receiving a third HTTP request message sent by the diagnostic device; wherein the third HTTP request message is generated by the diagnostic device according to the second HTTP response message, and the third HTTP request message is used to request a diagnosable resource in the target node; A third HTTP response message is generated according to the diagnosable resources in the target node, and the third HTTP response message is sent to the diagnostic device; wherein the diagnostic device is used to generate the first HTTP request message according to the third HTTP response message.

4. The method according to claim 3, characterized in that Before generating a second HTTP response message according to the diagnosable node in the vehicle, the method further includes: Determine the diagnosable nodes in the vehicle according to the node list file corresponding to the vehicle; Before generating the third HTTP response message according to the diagnosable resource in the target node, the method further includes: The diagnosable resources in the target node are determined according to the resource list file corresponding to the target node.

5. The method according to claim 4, characterized in that The determining the diagnosable nodes in the vehicle according to the node list file corresponding to the vehicle includes: Reading node codes of multiple nodes in the vehicle; The node codes of the plurality of nodes in the vehicle are matched with the node codes of the plurality of nodes in the node list file, and the nodes corresponding to the node codes that are matched successfully are determined as diagnosable nodes in the vehicle.

6. The method according to claim 4, characterized in that The resource list file corresponding to the target node includes a data resource list file and a log resource list file; and determining the diagnosable resources in the target node according to the resource list file corresponding to the target node includes: When the third HTTP request message is used to request the diagnosable data resources in the target node, querying the data resource list file corresponding to the target node to obtain the diagnosable data resources in the target node; When the third HTTP request message is used to request the diagnosable log resources in the target node, a query process is performed on the log resource list file corresponding to the target node to obtain the diagnosable log resources in the target node.

7. A vehicle diagnostic device, characterized in that: A master control node applied to a vehicle; the device comprises: A first receiving module is used to receive a first Hypertext Transfer Protocol (HTTP) request message sent by a diagnostic device; wherein the first HTTP request message is used to request a target resource in a target node; and the communication protocol used by the target node is a unified diagnostic service (UDS) communication protocol; A resource information acquisition module, used for converting the first HTTP request message into a UDS request message, and sending the UDS request message to the target node; The resource information acquisition module is further used to receive a UDS response message sent by the target node; wherein the UDS response message includes resource information of the target resource in the target node; The first sending module is used to convert the UDS response message into a first HTTP response message, and send the first HTTP response message to the diagnostic device.

8. A chip, characterized in that: The chip includes executable instructions, and the chip runs in a vehicle to implement the method according to any one of claims 1 to 6.

9. A vehicle, characterized in that: include: A memory for storing executable instructions; A processor, configured to implement the method according to any one of claims 1 to 6 when executing the executable instructions stored in the memory.

10. A computer-readable storage medium, characterized in that: Executable instructions are stored, and when executed by a processor, the method described in any one of claims 1 to 6 is implemented.

11. A computer program product, characterized in that The method comprises executable instructions for implementing the method according to any one of claims 1 to 6 when executed by a processor.

Images