A remote diagnosis method for vehicle-side Ethernet nodes based on SOA services

Abstract

The invention discloses a remote diagnosis method for a vehicle-side Ethernet node based on SOA service. The cloud sends a remote diagnosis instruction based on the MQTT protocol to TBOX. After receiving the remote diagnosis instruction sent by the cloud, TBOX converts the MQTT protocol into a DDS service request, and then performs remote diagnosis on each domain controller of the whole vehicle through the DDS service request. TBOX distributes a DoIP routing activation request message to the domain controller of the corresponding IP, and the domain controller receives the DoIP routing activation request message from TBOX. The domain controller sends an execution permission signal to TBOX, and responds to the routing activation message of TBOX in the form of DoIP. After TBOX receives the DoIP routing activation message sent by the domain controller, it sends a UDS diagnosis request message to the domain controller. After receiving the UDS diagnosis request message, the domain controller analyzes the UDS diagnosis request message and performs self-diagnosis, and packages the diagnosis result into a diagnosis message and sends it to TBOX in the form of DoIP. TBOX converts the diagnosis message in the DoIP form into the form of MQTT protocol and sends it to the cloud.

Description

Technical Field

[0001] The present invention relates to the technical field of vehicle fault diagnosis, and in particular to a remote diagnosis method of a vehicle-side Ethernet node based on SOA service. Background Art

[0002] As the complexity of vehicle control systems increases, the probability of failure increases. At present, the development of remote diagnosis technology for vehicle faults has enabled remote online diagnosis services to be realized, thereby reducing the time cost of sending the vehicle to a repair station and the driving risk during the repair process.

[0003] In the existing technology, there are technologies for remote diagnosis of vehicles, such as patent CN113778050A, which discloses a method for remote diagnosis of vehicles. However, this method requires the user to actively report the faulty parts of the vehicle before the parts can be detected. If the user cannot determine the source of the fault, remote diagnosis cannot be performed; and this method requires downloading a large amount of historical vehicle driving data, which takes a lot of time and traffic, greatly increasing the cost of remote diagnosis. Summary of the invention

[0004] In view of the above-mentioned deficiencies in the prior art, the technical problem to be solved by the present invention is: how to provide a remote diagnosis method for vehicle-side Ethernet nodes based on SOA services, which can enable the vehicle to independently determine the type of node that has failed, realize accurate and intelligent remote diagnosis, and reduce the difficulty of user use.

[0005] In order to solve the above technical problems, the present invention adopts the following technical solutions:

[0006] A remote diagnosis method for a vehicle-side Ethernet node based on SOA service comprises the following steps:

[0007] (1) The cloud sends remote diagnostic instructions based on the MQTT protocol to TBOX;

[0008] (2) TBOX receives the remote diagnosis command sent from the cloud, converts the MQTT protocol into a DDS service request, and then performs remote diagnosis on each domain controller of the vehicle through the DDS service request. TBOX distributes the DoIP routing activation request message to the domain controller of the corresponding IP, and the domain controller receives the DoIP routing activation request message from TBOX;

[0009] (3) The domain controller sends an execution permission signal to TBOX and responds to TBOX's routing activation message in the form of DoIP;

[0010] (4) After receiving the DoIP routing activation message from the domain controller, TBOX sends a UDS diagnosis request message to the domain controller. After receiving the UDS diagnosis request message, the domain controller analyzes the UDS diagnosis request message and performs self-diagnosis, and packages the diagnosis results into a diagnosis message and sends it to TBOX in the form of DoIP;

[0011] (5) TBOX converts the diagnostic message in DoIP format into MQTT protocol format and sends it to the cloud.

[0012] As an optimization, in step (1), when the cloud sends a remote diagnosis instruction to TBOX, TBOX determines whether there is an unfinished diagnosis task locally. If so, it feeds back a code representing "unfinished" to the cloud.

[0013] As an optimization, in step (2), when TBOX receives the remote diagnosis command sent from the cloud, TBOX determines the execution condition of the current command. When the vehicle is in the "vehicle power is OFF gear" and "vehicle speed is greater than 0" state, TBOX feeds back a code representing "cannot execute" to the cloud.

[0014] As an optimization, in step (3), before the domain controller sends a signal to allow execution to TBOX, the domain controller determines the diagnostic status of the entire vehicle. When the domain controller is performing local diagnosis or OTA upgrade, the domain controller sends a signal to TBOX not to allow execution. After receiving the signal, TBOX sends a code representing "error" to the cloud.

[0015] As an optimization, in step (2), after the domain controller receives the DoIP activation request message from TBOX, if the feedback response of the domain controller times out, TBOX feeds back code I representing "timeout" to the cloud. If the feedback response of the domain controller does not time out, it proceeds to step (3).

[0016] As an optimization, in step (4), after the domain controller receives the UDS diagnostic request message, if the domain controller times out in sending the diagnostic message response, TBOX feeds back a code II representing "timeout" to the cloud.

[0017] The cloud is used to remotely read diagnostic data, is responsible for sending diagnostic instructions to the vehicle-side remote control center, and receives and analyzes diagnostic data uploaded by the vehicle.

[0018] As the upper computer on the vehicle side, TBOX is responsible for determining whether the current vehicle status can be remotely diagnosed. If it cannot be diagnosed, it will feedback the corresponding error code; otherwise, it will receive and parse the diagnostic instructions sent from the cloud, address the faulty controller, and send the diagnostic results to the remote end after completing the diagnosis.

[0019] The domain controller is the specific object to be diagnosed in the present invention, which is arranged in the Ethernet of the vehicle body and is assigned a unique IP address. By comparing the address in the diagnostic instruction with the IP of the controller, it is possible to detect which controller has a fault.

[0020] Compared with the prior art, the present invention has the following beneficial effects: the present invention performs IP addressing on the controller nodes arranged in the vehicle body Ethernet by parsing the address information in DoIP, and then the diagnostic center autonomously determines the type of node that has failed through the calculation of certain rule algorithms, thereby realizing precise and intelligent remote diagnosis. After the diagnostic center analyzes and identifies the fault itself, the present invention only needs to transmit the DID, freeze frame, and DTC key diagnostic data of the faulty node to the cloud, avoiding the transmission of a large amount of useless data. BRIEF DESCRIPTION OF THE DRAWINGS

[0021] Figure 1 It is a schematic diagram of the process of the present invention;

[0022] Figure 2 This is a timing diagram of message sending between the cloud, TBOX and domain controller in the present invention. DETAILED DESCRIPTION

[0023] In order to make the purpose, technical scheme and advantages of the embodiments of the present invention clearer, the technical scheme in the embodiments of the present invention will be clearly and completely described below in conjunction with the drawings in the embodiments of the present invention. Obviously, the described embodiments are part of the embodiments of the present invention, not all of the embodiments. The components of the embodiments of the present invention generally described and shown in the drawings here can be arranged and designed in various different configurations. Therefore, the following detailed description of the embodiments of the present invention provided in the drawings is not intended to limit the scope of the claimed invention, but merely represents selected embodiments of the present invention. Based on the embodiments in the present invention, all other embodiments obtained by ordinary technicians in this field without making creative work belong to the scope of protection of the present invention.

[0024] like Figure 1 and Figure 2 As shown, a remote diagnosis method of a vehicle-side Ethernet node based on SOA service in this specific implementation manner includes the following steps:

[0025] (1) The cloud sends remote diagnostic instructions based on the MQTT protocol to TBOX;

[0026] (2) TBOX receives the remote diagnosis command sent from the cloud and converts the MQTT protocol into a DDS service request. The diagnostic center in TBOX uses a series of rule algorithms, such as whether there is a fault code with a relatively high severity level at the node, or the number of times a certain fault code has occurred in the recent time period, and then performs remote diagnosis on each domain controller of the vehicle through a DDS service request. TBOX distributes the DoIP routing activation request message to the domain controller of the corresponding IP, and the domain controller receives the DoIP routing activation request message from TBOX;

[0027] (3) The domain controller sends an execution permission signal to TBOX and responds to TBOX's routing activation message in the form of DoIP;

[0028] (4) After receiving the DoIP routing activation message from the domain controller, TBOX sends a UDS diagnosis request message to the domain controller. After receiving the UDS diagnosis request message, the domain controller analyzes the UDS diagnosis request message and performs self-diagnosis, and packages the diagnosis results into a diagnosis message and sends it to TBOX in the form of DoIP;

[0029] (5) TBOX converts the diagnostic message in DoIP format into MQTT protocol format and sends it to the cloud.

[0030] The present invention obtains the DID, freeze frame, and DTC data of the corresponding controller on the vehicle side by issuing remote reading instructions of DID, freeze frame, and DTC, and after the diagnosis is completed, issues a remote fault code clearing instruction to clear the DTC code of the corresponding controller. At the same time, the function of the remote reading DID or freeze frame channel can be expanded. For example, after receiving the DTC data uploaded by the vehicle side, the background can determine whether the corresponding DTC needs to immediately pull the relevant DID or freeze frame data through a specific application, and automatically issues a remote reading instruction to obtain the corresponding DID or freeze frame data if necessary.

[0031] There is a default response time from sending a diagnostic command from the cloud to getting a response message. During this process, all the diagnosed nodes reply with complete messages with positive responses. If a negative response occurs in a process, the process is terminated and the negative response message replied by the diagnostic node is returned to the cloud via MQTT.

[0032] In this specific implementation, in step (1), when the cloud sends a remote diagnosis instruction to TBOX, TBOX determines whether there is an unfinished diagnosis task locally. If so, it feeds back a code representing "unfinished" to the cloud.

[0033] In this specific implementation, in step (2), when TBOX receives the remote diagnosis command sent from the cloud, TBOX determines the execution condition of the current command. When the vehicle is in the "vehicle power is OFF gear" and "vehicle speed is greater than 0" state, TBOX feeds back a code representing "cannot execute" to the cloud.

[0034] In this specific implementation, in step (3), before the domain controller sends a signal to allow execution to TBOX, the domain controller determines the diagnostic status of the entire vehicle. When the domain controller is performing local diagnosis or OTA upgrade, the domain controller sends a signal to not allow execution to TBOX. After receiving the signal, TBOX sends a code representing "error" to the cloud.

[0035] In this specific implementation, in step (2), after the domain controller receives the DoIP activation request message from TBOX, if the feedback response of the domain controller times out, TBOX feeds back code I representing "timeout" to the cloud; if the feedback response of the domain controller does not time out, the process proceeds to step (3).

[0036] In this specific implementation, in step (4), after the domain controller receives the UDS diagnostic request message, if the domain controller times out in sending the diagnostic message response, the TBOX feeds back a code II representing "timeout" to the cloud.

[0037] All response times in this embodiment can be configured according to corresponding situations.

[0038] Finally, it should be noted that the above embodiments are only used to illustrate the technical solution of the present invention rather than to limit the technical solution. Those skilled in the art should understand that those modifications or equivalent substitutions of the technical solution of the present invention that do not depart from the purpose and scope of the technical solution should be included in the scope of the claims of the present invention.

Claims

1. A remote diagnosis method for vehicle-side Ethernet nodes based on SOA services, characterized in that: The following steps are involved: (1) The cloud sends remote diagnostic instructions based on the MQTT protocol to TBOX; (2) TBOX receives the remote diagnosis instruction sent from the cloud, converts the MQTT protocol into a DDS service request, and then performs remote diagnosis on each domain controller of the vehicle through the DDS service request. TBOX distributes the DoIP routing activation request message to the domain controller of the corresponding IP, and the domain controller receives the DoIP routing activation request message from TBOX. When the domain controller receives the DoIP activation request message from TBOX, if the feedback response of the domain controller times out, TBOX feeds back a code representing "timeout" I to the cloud, and performs IP addressing on the domain controller node by parsing the address information in DoIP. By comparing the address in the activation request message with the IP of the domain controller, it is detected which domain controller has a fault. If the feedback response of the domain controller does not time out, it proceeds to step (3). (3) The domain controller sends an execution permission signal to TBOX and responds to TBOX's routing activation message in the form of DoIP; (4) After receiving the DoIP routing activation message from the domain controller, TBOX sends a UDS diagnosis request message to the domain controller. After receiving the UDS diagnosis request message, the domain controller analyzes the UDS diagnosis request message and performs self-diagnosis, and packages the diagnosis results into a diagnosis message and sends it to TBOX in the form of DoIP; (5) TBOX converts the diagnostic message in DoIP format into MQTT protocol format and sends it to the cloud.

2. The remote diagnosis method of vehicle-side Ethernet node based on SOA service according to claim 1 is characterized in that: In step (1), when the cloud sends a remote diagnosis command to TBOX, TBOX determines whether there is an unfinished diagnosis task locally. If so, it feeds back a code representing "unfinished" to the cloud.

3. The remote diagnosis method of vehicle-side Ethernet node based on SOA service according to claim 1 is characterized in that: In step (2), when TBOX receives the remote diagnosis command sent by the cloud, TBOX determines the execution condition of the current command. When the vehicle is in the "vehicle power is OFF" and "vehicle speed is greater than 0" state, TBOX feeds back a code representing "cannot execute" to the cloud.

4. The remote diagnosis method of vehicle-side Ethernet node based on SOA service according to claim 1 is characterized in that: In step (3), before the domain controller sends a signal to allow execution to TBOX, the domain controller determines the diagnostic status of the vehicle. When the domain controller is performing local diagnosis or OTA upgrade, the domain controller sends a signal to TBOX not to allow execution. After receiving the signal, TBOX sends a code representing "error" to the cloud.

5. The remote diagnosis method of vehicle-side Ethernet node based on SOA service according to claim 1 is characterized in that: In step (4), after the domain controller receives the UDS diagnostic request message, if the domain controller times out in sending the diagnostic message response, TBOX feeds back a code II representing "timeout" to the cloud.

Images