Remote troubleshooting methods, remote troubleshooting systems and equipment for vehicle malfunctions

Abstract

This application discloses a remote fault handling method, system, and device for vehicle faults, belonging to the field of vehicle technology. This application enables remote diagnosis when a vehicle malfunctions. This remote diagnosis method not only shortens the vehicle fault investigation cycle, allowing for timely vehicle repair, but also significantly reduces costs because it eliminates the need to drive the vehicle to a repair center for on-site fault diagnosis by professionals. Furthermore, before the cloud server sends a diagnostic request to the vehicle, this application includes a comprehensive remote diagnostic initiation process. This process not only determines whether the current vehicle status meets the remote diagnostic requirements but also monitors the remote diagnostic process using multiple timers, providing strong support for remote fault handling.

Description

Technical Field

[0001] This application relates to the field of vehicles, and in particular to a remote fault handling method, remote fault handling system and equipment for vehicles. Background Technology

[0002] With the continuous improvement of living standards, vehicles have become increasingly common and an indispensable means of transportation in people's daily lives. However, vehicle malfunctions are inevitable during use.

[0003] In related technologies, when a vehicle malfunctions, on-site vehicle fault diagnosis is required. That is, the vehicle owner needs to drive the vehicle to a repair center, where professionals use diagnostic equipment to obtain vehicle fault information, and then analyze the problem to locate the fault and complete the repair.

[0004] However, the above process typically takes several days or longer, resulting in a lag in fault diagnosis. This leads to excessively long vehicle fault diagnosis times and low processing efficiency. Furthermore, since on-site vehicle fault diagnosis is required, it is not only costly but also inconvenient. Summary of the Invention

[0005] This application provides a remote fault handling method, a remote fault handling system, and a device. The technical solution is as follows:

[0006] On the one hand, a remote fault handling method for vehicles is provided, applied to a remote fault handling system, the system including a cloud server and a vehicle; the method includes:

[0007] The cloud server sends a remote diagnostic activation request to the vehicle and starts a first timer; wherein the first timer is used to record the duration of the cloud server's activation process.

[0008] Upon receiving the remote diagnostics activation request, the vehicle performs a remote diagnostics activation condition check and starts a second timer and a third timer. The remote diagnostics activation condition check is used to check whether the current vehicle status meets the remote diagnostic requirements. The duration of the second timer is less than the pre-configured diagnostic timeout. The third timer is used to record the duration of the vehicle activation process.

[0009] The vehicle sends a remote diagnostics activation response to the cloud server.

[0010] If the remote diagnostics activation response indication is successful, the cloud server sends a remote diagnostics request to the vehicle.

[0011] The vehicle obtains a diagnostic response based on the remote diagnostic request and sends the diagnostic response back to the cloud server.

[0012] The cloud server generates a fault handling strategy by parsing the diagnostic response and then sends the fault handling strategy to the vehicle.

[0013] When the remote diagnostics activation response indicates successful activation, the first timer and the third timer stop counting.

[0014] In one possible implementation, the vehicle includes a remote diagnostic master node; the execution of the remote diagnostic enable condition check includes at least one of the following:

[0015] The remote diagnostic master node checks the remaining power of the battery.

[0016] The remote diagnostic master node performs a timeout check on the third timer;

[0017] The remote diagnostic master node performs a task mutual exclusion check; wherein, the task mutual exclusion check is used to check whether there are other tasks with higher priority than the remote diagnostic task; or, the task mutual exclusion check is used to check whether there are other remote diagnostic tasks currently running.

[0018] In another possible implementation, during the remote diagnostics activation condition check, in response to any failure to meet an activation condition, the remote diagnostics activation fails, the vehicle terminates the check process, and the first timer and the third timer stop counting; or...

[0019] In response to the timeout of the third timer, remote diagnostics failed to start; or,

[0020] In response to the first timer timeout, remote diagnostics failed to start.

[0021] In another possible implementation, the vehicle further includes an onboard TBox; the method also includes:

[0022] The cloud server sends a remote diagnostic shutdown request using the first protocol format to the vehicle-mounted TBox;

[0023] The vehicle-mounted TBox sends a remote diagnostics shutdown request using the second protocol format to the remote diagnostics master node;

[0024] Upon receiving a remote diagnostic shutdown request using the second protocol format, the remote diagnostic master node controls the second timer to stop counting.

[0025] In another possible implementation, the method further includes:

[0026] In response to the second timer timeout, remote diagnostics are abnormally disabled; or,

[0027] In response to the abnormal disconnection of the TCP / TLS (Transmission Control Protocol / Transport Layer Security) link established between the cloud server and the remote diagnostic master node, the remote diagnostic system is abnormally shut down; or,

[0028] In response to the TCP / TLS link established between the cloud server and the remote diagnostic master node being disconnected due to a continuous lack of packets, the remote diagnostic system is abnormally shut down; or,

[0029] In response to an abnormal routing activation between the cloud server and the remote diagnostic master node, the remote diagnostic system is abnormally shut down.

[0030] In another possible implementation, the method further includes:

[0031] At the timeout of the second timer, in response to the absence of message transmission between the remote diagnostic master node and the cloud server, the remote diagnostic master node disconnects the TCP / TLS link; or,

[0032] When the second timer expires, in response to the existence of message transmission between the remote diagnostic master node and the cloud server, the remote diagnostic master node disconnects the TCP / TLS link if preset conditions are met;

[0033] The preset condition refers to the absence of an instruction from the cloud server within the first time period after the message transmission is completed.

[0034] In another possible implementation, the cloud server sends a remote diagnostics activation request to the vehicle, including:

[0035] The cloud server sends a remote diagnostic activation request using the first protocol format to the vehicle-mounted TBox;

[0036] The vehicle-mounted TBox converts the remote diagnostic activation request from the first protocol format to the second protocol format.

[0037] The vehicle-mounted TBox sends a remote diagnostics activation request using the second protocol format to the remote diagnostics master node.

[0038] In another possible implementation, the vehicle further includes an in-vehicle DoIP (Diagnostic Communication over Internet Protocol) node; the method further includes:

[0039] The cloud server establishes a TCP / TLS link with the remote diagnostic master node and sends a route activation request to the remote diagnostic master node;

[0040] The remote diagnostic master node performs route activation and sends a route activation response back to the cloud server.

[0041] The remote diagnostic master node establishes a TCP / TLS link with the DoIP node and sends a route activation request to the in-vehicle DoIP node.

[0042] The in-vehicle DoIP node performs route activation and sends a route activation response back to the remote diagnostic master node.

[0043] In another possible implementation, the vehicle obtains a diagnostic response based on the remote diagnostic request, including:

[0044] The remote diagnostic master node sends the remote diagnostic request to the in-vehicle DoIP node through the DoIP gateway; wherein, the remote diagnostic request includes the logical address of the destination node;

[0045] The destination node obtains the diagnostic response after receiving the remote diagnostic request.

[0046] In another possible implementation, where the in-vehicle DoIP node is a VIU (Vehicle Intranet Unit, vehicle domain controller), the method further includes:

[0047] In response to the destination node being a downstream node of the VIU, the VIU performs protocol conversion on the remote diagnostic request using the DoIP protocol format according to the protocol type supported by the downstream node, to obtain the remote diagnostic request using the third protocol format.

[0048] The third protocol is a protocol supported by the downstream node.

[0049] In another possible implementation, where changes to the vehicle controller's internal storage are required, the method further includes:

[0050] The cloud server sends a user authorization request to the target terminal;

[0051] The target terminal includes at least one of an in-vehicle terminal or a mobile terminal; the user authorization request is used to request permission to be granted within a second time period.

[0052] On the other hand, a remote fault handling system is provided, the system including a cloud server and a vehicle;

[0053] The cloud server is used to send a remote diagnostic activation request to the vehicle and start a first timer; wherein the first timer is used to record the duration of the cloud server's activation process.

[0054] The vehicle is configured to perform a remote diagnostics activation condition check and start a second timer and a third timer after receiving the remote diagnostics activation request; wherein, the remote diagnostics activation condition check is used to check whether the current vehicle status meets the remote diagnostic requirements; the duration of the second timer is less than the pre-configured diagnostic time limit; the third timer is used to record the duration of the vehicle activation process;

[0055] The vehicle is also used to send a remote diagnostic activation response to the cloud server;

[0056] The cloud server is also used to send a remote diagnostic request to the vehicle when the remote diagnostic activation response indication is successfully activated.

[0057] The vehicle is also configured to obtain a diagnostic response based on the remote diagnostic request and send the diagnostic response back to the cloud server;

[0058] The cloud server is also used to generate a fault handling strategy by parsing the diagnostic response and to send the fault handling strategy to the vehicle;

[0059] When the remote diagnostics activation response indicates successful activation, the first timer and the third timer stop counting.

[0060] In one possible implementation, the remote diagnostic master node is used to perform at least one of the following:

[0061] Check the remaining power of the battery;

[0062] Perform a timeout check on the third timer;

[0063] Perform a task mutual exclusion check; wherein the task mutual exclusion check is used to check whether there are other tasks with higher priority than the remote diagnostic task; or, the task mutual exclusion check is used to check whether there are other remote diagnostic tasks currently running.

[0064] In another possible implementation, during the remote diagnostics activation condition check, in response to any failure to meet an activation condition, the remote diagnostics activation fails, the vehicle terminates the check process, and the first timer and the third timer stop counting; or...

[0065] In response to the timeout of the third timer, remote diagnostics failed to start; or,

[0066] In response to the first timer timeout, remote diagnostics failed to start.

[0067] In another possible implementation, the cloud server is also used to send the remote diagnostic shutdown request using a first protocol format to the in-vehicle TBox;

[0068] The vehicle-mounted TBox is used to send a remote diagnostic shutdown request using the second protocol format to the remote diagnostic master node;

[0069] The remote diagnostic master node is also configured to control the second timer to stop counting after receiving a remote diagnostic shutdown request using the second protocol format.

[0070] In another possible implementation, remote diagnostics are shut down in response to the second timer timeout; or,

[0071] In response to the abnormal disconnection of the Transmission Control Protocol (TCP / TLS) link established between the cloud server and the remote diagnostic master node, the remote diagnostic system is abnormally shut down; or,

[0072] In response to the TCP / TLS link established between the cloud server and the remote diagnostic master node being disconnected due to a continuous lack of packets, the remote diagnostic system is abnormally shut down; or,

[0073] In response to an abnormal routing activation between the cloud server and the remote diagnostic master node, the remote diagnostic system is abnormally shut down.

[0074] In another possible implementation, the remote diagnostic master node is also used for:

[0075] At the timeout of the second timer, in response to the absence of message transmission between the remote diagnostic master node and the cloud server, the TCP / TLS link is disconnected; or,

[0076] When the second timer expires, in response to the existence of message transmission between the remote diagnostic master node and the cloud server, the TCP / TLS link is disconnected if preset conditions are met;

[0077] The preset condition refers to the absence of an instruction from the cloud server within the first time period after the message transmission is completed.

[0078] In another possible implementation, the cloud server is also used to send the remote diagnostic activation request using a first protocol format to the vehicle TBox;

[0079] The vehicle-mounted TBox is also used to convert the remote diagnostic activation request from the first protocol format to the second protocol format;

[0080] The vehicle-mounted TBox is also used to send a remote diagnostics activation request using the second protocol format to the remote diagnostics master node.

[0081] In another possible implementation, the vehicle also includes an in-vehicle DoIP node;

[0082] The cloud server is also used to establish a TCP / TLS link with the remote diagnostic master node and send a route activation request to the remote diagnostic master node;

[0083] The remote diagnostic master node is also used to perform route activation and send a route activation response back to the cloud server;

[0084] The remote diagnostic master node is also used to establish the TCP / TLS link with the DoIP node and send a route activation request to the in-vehicle DoIP node;

[0085] The in-vehicle DoIP node is used to perform route activation and send a route activation response back to the remote diagnostic master node.

[0086] In another possible implementation, the remote diagnostic master node is also used to send the remote diagnostic request to the in-vehicle DoIP node through the DoIP gateway; wherein the remote diagnostic request includes the logical address of the destination node;

[0087] The destination node is used to obtain the diagnostic response after receiving the remote diagnostic request.

[0088] In another possible implementation, when the in-vehicle DoIP node is a VIU, the VIU is used to respond to the destination node being a downstream node of the VIU, and according to the protocol type supported by the downstream node, to perform protocol conversion on the remote diagnostic request using the DoIP protocol format to obtain the remote diagnostic request using a third protocol format.

[0089] The third protocol is a protocol supported by the downstream node.

[0090] In another possible implementation, the cloud server is also used to send a user authorization request to the target terminal when it is necessary to change the internal storage of the vehicle controller.

[0091] The target terminal includes at least one of an in-vehicle terminal or a mobile terminal; the user authorization request is used to request permission to be granted within a second time period.

[0092] On the other hand, a computer device is provided, the device including a processor and a memory, the memory storing at least one piece of program code, the at least one piece of program code being loaded and executed by the processor to implement the above-described remote handling method for vehicle malfunctions.

[0093] On the other hand, a computer-readable storage medium is provided, wherein at least one piece of program code is stored therein, the at least one piece of program code being loaded and executed by a processor to implement the above-described remote handling method for vehicle malfunctions.

[0094] On the other hand, a computer program product or computer program is provided, which includes computer program code stored in a computer-readable storage medium. A processor of a computer device reads the computer program code from the computer-readable storage medium and executes the computer program code, causing the computer device to perform the aforementioned remote vehicle fault handling method.

[0095] The embodiments of this application enable remote diagnosis when a vehicle malfunctions. This remote diagnosis method not only shortens the investigation cycle of vehicle malfunctions and allows for timely vehicle repair, but also significantly reduces costs because it eliminates the need to drive the vehicle to a repair center for on-site fault diagnosis by professionals.

[0096] In addition, before the cloud server sends a diagnostic request to the vehicle, the embodiments of this application also include a comprehensive remote diagnostic activation process. This process can not only determine whether the current vehicle status meets the remote diagnostic requirements, but also monitor the remote diagnostic through multiple timers, which provides a strong guarantee for the remote handling of vehicle faults. Attached Figure Description

[0097] To more clearly illustrate the technical solutions in the embodiments of this application, the accompanying drawings used in the description of the embodiments will be briefly introduced below. Obviously, the accompanying drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0098] Figure 1 This is a schematic diagram of an implementation environment for remote UDS diagnostics provided in an embodiment of this application;

[0099] Figure 2 This is a schematic diagram of the architecture of a remote UDS diagnostic solution provided in an embodiment of this application;

[0100] Figure 3 This is a flowchart of a remote vehicle fault handling method provided in an embodiment of this application;

[0101] Figure 4 This is a schematic diagram illustrating a remote diagnostic enabling / disabling management method provided in an embodiment of this application;

[0102] Figure 5 This is a schematic diagram of the operation logic of a remote UDS diagnostic provided in an embodiment of this application;

[0103] Figure 6 This is a schematic diagram of the operating logic of another remote UDS diagnostic provided in an embodiment of this application;

[0104] Figure 7 This is a schematic diagram of the structure of a remote fault handling system provided in an embodiment of this application;

[0105] Figure 8 This is a schematic diagram of the structure of a computer device provided in an embodiment of this application;

[0106] Figure 9 This is a schematic diagram of the structure of another computer device provided in an embodiment of this application. Detailed Implementation

[0107] To make the objectives, technical solutions, and advantages of this application clearer, the embodiments of this application will be described in further detail below with reference to the accompanying drawings.

[0108] In this application, the terms "first," "second," etc., are used to distinguish identical or similar items that have essentially the same function. It should be understood that there is no logical or temporal dependency between "first," "second," and "nth," nor does it limit the quantity or execution order. It should also be understood that although the following description uses the terms "first," "second," etc., to describe various elements, these elements should not be limited by the terms.

[0109] These terms are simply used to distinguish one element from another. For example, without departing from the various examples, the first element can be referred to as the second element, and similarly, the second element can be referred to as the first element. Both the first and second elements can be elements, and in some cases, they can be separate and distinct elements.

[0110] "At least one" refers to one or more elements. For example, at least one element can be one element, two elements, three elements, or any integer number of elements greater than or equal to one. "Multiple" refers to two or more elements. For example, multiple elements can be two elements, three elements, or any integer number of elements greater than or equal to two.

[0111] In this article, "and / or" indicates that three relationships can exist. For example, A and / or B can represent: A alone, A and B simultaneously, or B alone. The character " / " generally indicates that the preceding and following objects are in an "or" relationship.

[0112] It should be noted that the information (including but not limited to user device information, user personal information, etc.), data (including but not limited to data used for analysis, data stored, data displayed, etc.) and signals involved in this application are all authorized by the user or fully authorized by all parties, and the collection, use and processing of related data must comply with the relevant laws, regulations and standards of the relevant regions.

[0113] This application proposes a remote fault handling method and system. The remote diagnostic scheme proposed in this application is based on the UDS (Unified Diagnostic Services) protocol; therefore, the aforementioned remote fault handling system is also referred to as a remote UDS diagnostic system. In summary, this remote diagnostic scheme remotely sends diagnostic requests to the vehicle via the cloud and obtains the vehicle's diagnostic response, thereby enabling remote, contactless diagnostic interaction.

[0114] Figure 1 This is a schematic diagram of an implementation environment for remote UDS diagnostics provided in an embodiment of this application. See also... Figure 1 The implementation environment includes vehicles and the cloud (also known as vehicle cloud or cloud server).

[0115] When a vehicle malfunctions, professionals (such as R&D / maintenance personnel) can perform remote UDS diagnostics based on the vehicle cloud without physically touching the vehicle. This allows them to query vehicle information, locate the fault, and provide repair suggestions, offering users a convenient way to repair their vehicles. Additionally, vehicle owners can also manage remote diagnostics and authorization through an app installed on their smart devices.

[0116] like Figure 1 As shown, remote UDS diagnostics mainly consists of three parts: remote wake-up management, remote diagnostics activation / deactivation, and remote diagnostics execution. Remote wake-up management includes: remote wake-up, wake-up retention, and exit. Remote diagnostics activation / deactivation includes: remote diagnostics activation, remote diagnostics deactivation, activation failure, or activation / deactivation rollback. Remote diagnostics execution includes: connection establishment and route activation, command filtering, diagnostic routing, and execution of requests and responses.

[0117] The following is combined Figure 2 The schematic diagram of the remote UDS diagnostic scheme shown below provides a brief description of the remote diagnostic scheme provided in this application embodiment.

[0118] 1. The cloud server sends a remote diagnostics activation request to the vehicle via the in-vehicle TBox. Upon receiving the request, the vehicle checks the activation conditions. If all conditions are met, the vehicle sends a successful remote diagnostics activation response back to the cloud server.

[0119] See Figure 2 The cloud server sends a remote diagnostics activation request in the form of an MQTT (Message Queuing Telemetry Transport) message to the in-vehicle TBox. The in-vehicle TBox performs protocol conversion, obtaining a remote diagnostics activation request in the form of a SOME / IP (Service-Oriented Middleware over IP) message, and sends it to the vehicle's remote diagnostics master node. In this example, the diagnostic gateway node is the VDC (Vehicle Control Data Computing Center). In addition to the VDC, any in-vehicle DoIP node that meets the requirements for a remote diagnostics master node (such as operating system requirements, hardware requirements, and storage space requirements) can also serve as a remote diagnostics master node. This embodiment only uses the VDC as the remote diagnostics master node for illustrative purposes.

[0120] The in-vehicle TBox converts the above response in SOME / IP message format into an MQTT message and sends it to the cloud server, which then receives the response.

[0121] 2. The cloud server establishes a connection and activates routing with the vehicle (VDC), and the VDC establishes a connection and activates routing with the in-vehicle DoIP node.

[0122] like Figure 2 As shown, the in-vehicle DoIP node includes an ECU (Electronic Control Unit) that supports the DoIP protocol. The in-vehicle DoIP node can be a CDC (Cockpit Domain Controller), an autonomous driving domain controller, or a VIU, etc., and this application does not limit this to any particular type.

[0123] 3. The cloud server sends a diagnostic request to the vehicle. The diagnostic request is routed to the corresponding destination node. The destination node executes the diagnostic request, obtains a diagnostic response, and sends the diagnostic response back to the cloud server according to the path it received the diagnostic request. The remote UDS diagnostic service platform of the cloud server parses the diagnostic response and presents the final result.

[0124] like Figure 2As shown, diagnostic request routing may involve protocol conversion between DoIPs, between DoIP and DOCAN (UDS diagnostics based on CAN bus), between DoIP and DOCANFD (UDS diagnostics based on CAN-FD bus), and between DoIP and DoLIN.

[0125] 4. If it is necessary to modify the internal storage of the vehicle controller, the cloud server needs to obtain user authorization, as detailed below.

[0126] Figure 3 This is a flowchart illustrating a remote vehicle fault handling method provided in an embodiment of this application. The method is applied to a remote fault handling system, which includes a cloud server and a vehicle. See also... Figure 3 The method includes the following steps:

[0127] 301. The cloud server sends a remote diagnostics start request to the vehicle and starts the first timer.

[0128] Combination Figure 4 and Figure 5 As can be seen, when the vehicle wakes up from hibernation and the in-vehicle TBox logs into the cloud server, the cloud server sends a remote diagnostics activation request to the vehicle. The vehicle then begins an activation condition check and sends the results back to the cloud server. Additionally, if the activation condition check fails, the cloud server terminates the remote diagnostics operation, or an anomaly occurs, a remote diagnostics deactivation and rollback operation will be performed, as detailed below.

[0129] In this embodiment, the cloud server sends a remote diagnostics enable request using a first protocol format to the in-vehicle TBox; the in-vehicle TBox then converts the remote diagnostics enable request from the first protocol format to a second protocol format, and then sends a remote diagnostics enable request using the second protocol format to the vehicle's VDC. Exemplarily, the first protocol is MQTT and the second protocol is SOME / IP; this application does not limit the specific protocol used.

[0130] It should be noted that the first timer (also known as timer T2) is used to record the duration of cloud server processing.

[0131] 302. After receiving a remote diagnostics activation request, the vehicle performs a remote diagnostics activation condition check and starts the second and third timers.

[0132] In this embodiment, the remote diagnostic activation condition check is used to check whether the current vehicle status meets the remote diagnostic requirements. Specifically, the duration of the second timer (also called timer T1) is less than the pre-configured diagnostic timeout; the third timer (also called timer T3) is used to record the duration of the vehicle activation process.

[0133] For example, performing a remote diagnostic enablement condition check includes at least one of the following:

[0134] 1. VDC checks the remaining power of the battery.

[0135] VDC checks the remaining power of the main battery; if the remaining power of the main battery is low (the threshold is configurable; for example, for lithium batteries, it is recommended that the remaining power be greater than 55%), the startup will fail (reason for failure: low remaining power of the main battery).

[0136] 2. VDC performs a timeout check on the third timer.

[0137] If VDC determines that timer T3 has timed out during the startup preparation process, startup will fail (reason for failure: operation timeout).

[0138] 3. VDC performs mutual exclusion checks on task execution.

[0139] In this embodiment of the application, the task mutual exclusion check is used to check whether there are other tasks with higher priority than the remote diagnostic task; or, the task mutual exclusion check is used to check whether there are other remote diagnostic tasks currently running.

[0140] For example, when VDC performs task mutual exclusion judgment, it performs arbitration mutual exclusion processing according to the principle of priority arbitration: if there is a service with a higher priority than remote UDS diagnosis (such as near-end OBD diagnosis / upgrade, OTA upgrade, or cockpit central control diagnosis, etc.), it reports remote diagnosis failure to the cloud server (failure reason: task mutual exclusion). Additionally, if there is a currently running remote UDS diagnosis service, it reports remote diagnosis failure to the cloud server (failure reason: task mutual exclusion).

[0141] In summary, such as Figure 4 and Figure 5 As shown, the remote diagnostics activation process is as follows: The cloud server sends a remote diagnostics activation request (MQTT message) to the vehicle TBox and triggers the "Cloud Activation Processing" timer T2 (default duration 1 minute, configurable); the vehicle TBox converts the MQTT message into a SOME / IP message and sends the SOME / IP message to the VDC; after receiving the remote diagnostics activation request, the VDC triggers the "Diagnostic Duration" timer T1 (default duration 1 hour, configurable); in addition, after receiving the remote diagnostics activation request, the VDC will also trigger the "Local Activation Processing" timer T3 (default duration 30 seconds, configurable).

[0142] 303. The vehicle sends a remote diagnostic response to the cloud server.

[0143] In this embodiment, when the remote diagnostics activation response indicates successful activation (i.e., all conditions in the activation condition check are met), the VDC will send a successful activation SOME / IP message to the vehicle TBox and simultaneously stop timer T3. Upon receiving the successful activation SOME / IP message, the vehicle TBox will convert it into an MQTT message and send it to the cloud server. The cloud server, upon receiving the successful activation feedback, will stop timer T2.

[0144] In addition, such as Figure 4 As shown, during the remote diagnostic activation condition check, if any activation condition is not met, or if timer T2 or timer T3 times out, the remote diagnostic activation fails. The VDC stops subsequent checks, terminating the check process, performing a rollback operation, and sending a SOME / IP message indicating activation failure to the vehicle's TBox. Simultaneously, timer T3 is stopped. Upon receiving a successful activation SOME / IP message, the vehicle's TBox converts it into an MQTT message and sends it to the cloud server. The cloud server, upon receiving the activation failure feedback, stops timer T2.

[0145] like Figure 5 As shown, if the startup is successful, the chain establishment and routing activation process will begin.

[0146] For establishing a connection and activating routes between the cloud and the vehicle, the cloud server establishes a TCP / TLS link with the VDC. Additionally, the cloud server sends a route activation request to the VDC, which then performs the route activation and sends a route activation response back to the cloud server.

[0147] 304. When the remote diagnostics activation response indicates successful activation, the cloud server sends a remote diagnostics request to the vehicle.

[0148] For establishing a connection and activating routes between the VDC and the in-vehicle DoIP nodes, the VDC establishes a TCP / TLS link with the in-vehicle DoIP nodes. Additionally, the VDC sends a route activation request to the in-vehicle DoIP nodes, which then perform the route activation and send a route activation response back to the VDC.

[0149] For example, such as Figure 2 As shown, the remote UDS diagnostic service platform sends diagnostic messages to the vehicle through port 3496, and the VDC's remote diagnostic agent also receives diagnostic messages through port 3496.

[0150] 305. The vehicle obtains a diagnostic response based on a remote diagnostic request and sends the diagnostic response back to the cloud server.

[0151] The remote diagnostic request includes the logical address of the destination node. For example... Figure 2 As shown, the VDC sends a remote diagnostic request to the in-vehicle DoIP node via the DoIP gateway. Additionally, as... Figure 6 As shown, the routing of remote diagnostic requests includes vehicle diagnostic routes and intra-domain diagnostic routes.

[0152] For vehicle diagnostic routing, VDC supports routing remote diagnostic requests between in-vehicle DoIP nodes, meaning remote diagnostic requests are transmitted between in-vehicle DoIP nodes. Similarly, VDC also supports routing diagnostic responses between in-vehicle DoIP nodes, which are then fed back to the cloud.

[0153] For intra-domain diagnostic routing, when an in-vehicle DoIP node receives a remote diagnostic request from a destination node for one of its downstream nodes, it first performs protocol conversion based on the downstream node type (e.g., DoIP to DoCAN / DoCANFD / DoLIN), and then forwards the converted remote diagnostic request to the corresponding downstream node. Upon receiving the remote diagnostic request, the destination node executes the remote diagnostic request and generates a diagnostic response based on its own status conditions and the specific content of the request.

[0154] Based on the above description, it can be seen that, Figure 2 As described above, when the in-vehicle DoIP node is a VIU, the method provided in this application embodiment further includes: in response to a downstream node whose destination node is a VIU, the VIU performs protocol conversion on the remote diagnostic request using the DoIP protocol format according to the protocol type supported by the downstream node, to obtain a remote diagnostic request using a third protocol format. The third protocol is a protocol supported by the downstream node. For example, the third protocol could be DoCAN / DoCANFD / DoLIN, and this application does not limit this to a specific protocol.

[0155] In the embodiments of this application, such as Figure 4 and Figure 6 As shown, remote diagnostic shutdown includes normal shutdown (active shutdown via the cloud) and abnormal shutdown.

[0156] It should be noted that, Figure 5 and Figure 6 Taken together, this constitutes the overall process of remote diagnostic operation logic.

[0157] For normal shutdown, the cloud server sends a remote diagnostic shutdown request (MQTT message) to the vehicle TBox; after converting the MQTT message into a SOME / IP message, the vehicle TBox sends a remote diagnostic shutdown request in the form of a SOME / IP message to the VDC; after receiving the remote diagnostic shutdown request, the VDC stops the timer T1, performs a rollback operation, and returns a remote diagnostic shutdown response to the cloud.

[0158] For abnormal shutdowns, remote diagnostics of abnormal shutdowns will be triggered if any of the following conditions are detected.

[0159] 1. VDC timeout timer T1 expired.

[0160] In this situation, if there is no diagnostic message exchange between VDC and the cloud when timer T1 times out, VDC will actively disconnect and remote diagnostics will be abnormally shut down.

[0161] 2. The TCP / TLS link between the cloud and VDC was disconnected due to an anomaly, and remote diagnostics were abnormally shut down.

[0162] In this situation, the TCP / TLS link established between the cloud server and the VDC is disconnected due to an anomaly.

[0163] 3. The TCP / TLS link between the cloud and VDC was disconnected due to a continuous lack of packets, and remote diagnostics were abnormally shut down.

[0164] In this situation, the TCP / TLS link established between the cloud server and the VDC is disconnected due to the lack of continuous packets.

[0165] 4. Abnormal activation of cloud and VDC routing leads to abnormal shutdown of remote diagnostics.

[0166] In response to this situation, the system remotely diagnoses and shuts down the system in response to an abnormal routing activation between the cloud server and the VDC.

[0167] In one possible implementation, when timer T1 times out, in response to the lack of message transmission between the VDC and the cloud server, i.e., the absence of diagnostic message interaction, the VDC actively disconnects the TCP / TLS link, and the remote diagnostics are abnormally shut down.

[0168] In another possible implementation, when timer T1 expires, in response to the existence of message transmission between VDC and the cloud server, VDC actively disconnects the TCP / TLS link and remotely diagnoses the abnormal shutdown if preset conditions are met.

[0169] The preset condition refers to the absence of a command from the cloud server within the first time interval after message transmission is completed. Taking a first time interval of 15 seconds as an example, if there is still interaction between the VDC and the cloud for diagnostic messages when timer T1 expires, timer T1 will be actively delayed until the diagnostic message transmission is completed. If the VDC does not receive a command from the cloud server within 15 seconds after the message transmission is completed, the VDC will actively disconnect.

[0170] 306. The cloud server generates a fault handling strategy by parsing the diagnostic response and then distributes the fault handling strategy to the vehicle.

[0171] In addition to the vehicle-mounted terminal, the cloud server can also distribute fault handling strategies to the mobile terminal used by the user, which is not limited in this application.

[0172] In this application embodiment, the functions of the remote UDS diagnostic service platform include, but are not limited to:

[0173] 1. Account permission management.

[0174] 2. Vehicle Management: Vehicles can be managed and queried using their VIN (Vehicle Identification Number).

[0175] 3. Online diagnostics: For online vehicles, it provides all the diagnostic functions of a diagnostic tool.

[0176] 4. Diagnostic Sequence Management: Creation, modification, deletion, and querying of diagnostic sequences (with logical flow).

[0177] 5. Database Management: Uploading, downloading, listing, delisting, and querying ODX (Open Diagnostic Data Exchange) databases.

[0178] 6. Operation Log Management: Recording, storing, and querying operation logs.

[0179] In one possible implementation, when it is necessary to modify the internal storage of the vehicle controller (e.g., write services, routine services, clear fault codes, etc.), the method provided in this application embodiment further includes: a cloud server sending a user authorization request to a target terminal. The target terminal includes at least one of an in-vehicle terminal or a mobile terminal; the user authorization request is used to request permission for a specific function within a second time period.

[0180] In addition, the second duration can be configured as 7 days / 14 days / 30 days, etc., and this application does not limit it.

[0181] For example, the user authorization process is as follows:

[0182] a. Personnel responsible for remote UDS diagnostics log in to the remote UDS diagnostic service platform, query the vehicle status using the vehicle's VIN, and verify the information by entering the vehicle owner's terminal number. After successful verification and matching, the cloud server pushes a "Remote Diagnostic Authorization" message pop-up reminder to the APP installed on the vehicle owner's mobile terminal. In addition, authorization message reminders can also be pushed to the vehicle owner's mobile terminal simultaneously via SMS.

[0183] b. After the car owner clicks to enter the "Remote Diagnostic Authorization" function page, the APP displays a brief explanation of "Remote Diagnostic Authorization" and the "Agree" button for "Remote Diagnostic Authorization".

[0184] c. If the vehicle owner clicks "Agree," the mobile device used by the owner will send an authorization message for remote diagnostics to the cloud via the app. After receiving the authorization message, the cloud confirms that it has obtained user authorization and can proceed with tasks such as clearing vehicle fault codes.

[0185] d. If the user does not click the "Agree" button within 2 minutes (configurable), a prompt to cancel authorization will be displayed.

[0186] e. Car owners can revoke authorization at any time via the app.

[0187] The embodiments of this application enable remote diagnosis when a vehicle malfunctions. This remote diagnosis method not only shortens the investigation cycle of vehicle malfunctions and allows for timely vehicle repair, but also significantly reduces costs because it eliminates the need to drive the vehicle to a repair center for on-site fault diagnosis by professionals.

[0188] In addition, before the cloud server sends a diagnostic request to the vehicle, the embodiments of this application also include a comprehensive remote diagnostic activation process. This process can not only determine whether the current vehicle status meets the remote diagnostic requirements, but also monitor the remote diagnostic through multiple timers, which provides a strong guarantee for the remote handling of vehicle faults.

[0189] In addition, this application provides detailed descriptions of remote diagnostics activation and deactivation in different scenarios. In particular, for remote diagnostics activation failure and abnormal deactivation, this application provides judgment conditions and handling measures, which provides strong support for subsequent remote diagnostics execution.

[0190] Figure 7 This is a schematic diagram of the structure of a remote fault handling system provided in an embodiment of this application. See also... Figure 7 The system includes a cloud server 701 and a vehicle 702.

[0191] The cloud server 701 is used to send a remote diagnostic start request to the vehicle 702 and start a first timer; wherein, the first timer is used to record the duration of the start process of the cloud server 701.

[0192] Vehicle 702 is configured to perform a remote diagnostics activation condition check and start a second timer and a third timer after receiving the remote diagnostics activation request; wherein, the remote diagnostics activation condition check is used to check whether the current vehicle status meets the remote diagnostic requirements; the duration of the second timer is less than the pre-configured diagnostic time limit; the third timer is used to record the duration of the vehicle 702 activation process;

[0193] Vehicle 702 is also used to send a remote diagnostic activation response to the cloud server;

[0194] The cloud server 701 is also used to send a remote diagnostic request to the vehicle 702 when the remote diagnostic activation response indication is successfully activated.

[0195] Vehicle 702 is also used to obtain a diagnostic response based on the remote diagnostic request and to feed the diagnostic response back to cloud server 701;

[0196] The cloud server 701 is also used to generate a fault handling strategy by parsing the diagnostic response and to send the fault handling strategy to the vehicle 702;

[0197] When the remote diagnostics activation response indicates successful activation, the first timer and the third timer stop counting.

[0198] The embodiments of this application enable remote diagnosis when a vehicle malfunctions. This remote diagnosis method not only shortens the investigation cycle of vehicle malfunctions and allows for timely vehicle repair, but also significantly reduces costs because it eliminates the need to drive the vehicle to a repair center for on-site fault diagnosis by professionals.

[0199] In addition, before the cloud server sends a diagnostic request to the vehicle, the embodiments of this application also include a comprehensive remote diagnostic activation process. This process can not only determine whether the current vehicle status meets the remote diagnostic requirements, but also monitor the remote diagnostic through multiple timers, which provides a strong guarantee for the remote handling of vehicle faults.

[0200] In one possible implementation, the remote diagnostic master node is used to perform at least one of the following:

[0201] Check the remaining power of the battery;

[0202] Perform a timeout check on the third timer;

[0203] Perform a task mutual exclusion check; wherein the task mutual exclusion check is used to check whether there are other tasks with higher priority than the remote diagnostic task; or, the task mutual exclusion check is used to check whether there are other remote diagnostic tasks currently running.

[0204] In another possible implementation, during the remote diagnostic activation condition check, in response to any activation condition not being met, the remote diagnostic activation fails, vehicle 702 terminates the check process, and the first timer and the third timer stop counting; or, in response to the third timer timeout, the remote diagnostic activation fails; or, in response to the first timer timeout, the remote diagnostic activation fails.

[0205] In another possible implementation, the cloud server 701 is also used to send the remote diagnostic shutdown request using the first protocol format to the vehicle TBox;

[0206] The vehicle-mounted TBox is used to send a remote diagnostic shutdown request using the second protocol format to the remote diagnostic master node;

[0207] The remote diagnostic master node is also configured to control the second timer to stop counting after receiving a remote diagnostic shutdown request using the second protocol format.

[0208] In another possible implementation, remote diagnostics are shut down in response to the second timer timeout; or,

[0209] In response to the abnormal disconnection of the Transmission Control Protocol (TCP / TLS) link established between the cloud server and the remote diagnostic master node, the remote diagnostic system is abnormally shut down; or,

[0210] In response to the TCP / TLS link established between the cloud server and the remote diagnostic master node being disconnected due to a continuous lack of packets, the remote diagnostic system is abnormally shut down; or,

[0211] In response to an abnormal routing activation between the cloud server and the remote diagnostic master node, the remote diagnostic system is abnormally shut down.

[0212] In another possible implementation, the remote diagnostic master node is also used for:

[0213] At the timeout of the second timer, in response to the lack of message transmission between the remote diagnostic master node and the cloud server 701, the TCP / TLS link is disconnected; or,

[0214] When the second timer expires, in response to the existence of message transmission between the remote diagnostic master node and the cloud server 701, the TCP / TLS link is disconnected if preset conditions are met;

[0215] The preset condition refers to the absence of an instruction from the cloud server 701 within the first time period after the message transmission is completed.

[0216] In another possible implementation, the cloud server 701 is also used to send the remote diagnostic activation request using the first protocol format to the vehicle TBox;

[0217] The vehicle-mounted TBox is also used to convert the remote diagnostic activation request from the first protocol format to the second protocol format;

[0218] The vehicle-mounted TBox is also used to send a remote diagnostics activation request using the second protocol format to the remote diagnostics master node.

[0219] In another possible implementation, vehicle 702 also includes an in-vehicle DoIP node;

[0220] The cloud server 701 is also used to establish a TCP / TLS link with the remote diagnostic master node and send a route activation request to the remote diagnostic master node;

[0221] The remote diagnostic master node is also used to perform route activation and send a route activation response back to the cloud server 701;

[0222] The remote diagnostic master node is also used to establish the TCP / TLS link with the DoIP node and send a route activation request to the in-vehicle DoIP node;

[0223] The in-vehicle DoIP node is used to perform route activation and send a route activation response back to the remote diagnostic master node.

[0224] In another possible implementation, the remote diagnostic master node is also used to send the remote diagnostic request to the in-vehicle DoIP node through the DoIP gateway; wherein the remote diagnostic request includes the logical address of the destination node;

[0225] The destination node is used to obtain the diagnostic response after receiving the remote diagnostic request.

[0226] In another possible implementation, when the in-vehicle DoIP node is a VIU, the VIU is used to respond to the destination node being a downstream node of the VIU, and according to the protocol type supported by the downstream node, to perform protocol conversion on the remote diagnostic request using the DoIP protocol format to obtain the remote diagnostic request using a third protocol format.

[0227] The third protocol is a protocol supported by the downstream node.

[0228] In another possible implementation, the cloud server 701 is also used to send a user authorization request to the target terminal when it is necessary to change the internal storage of the vehicle controller.

[0229] The target terminal includes at least one of an in-vehicle terminal or a mobile terminal; the user authorization request is used to request permission to be granted within a second time period.

[0230] All of the above-mentioned optional technical solutions can be combined in any way to form the optional embodiments of this application, and will not be described in detail here.

[0231] It should be noted that the remote fault handling system provided in the above embodiments is only illustrated by the division of the above functional modules when remotely handling vehicle faults. In actual applications, the above functions can be assigned to different functional modules as needed, that is, the internal structure of the system can be divided into different functional modules to complete all or part of the functions described above. In addition, the remote fault handling system provided in the above embodiments and the remote vehicle fault handling method embodiments belong to the same concept, and the specific implementation process can be found in the method embodiments, which will not be repeated here.

[0232] Figure 8 This is a schematic diagram of the structure of a computer device 800 provided in an embodiment of this application.

[0233] Typically, computer device 800 includes a processor 801 and a memory 802.

[0234] Processor 801 includes one or more processing cores, such as a quad-core processor or an octa-core processor. Processor 801 is implemented using at least one of the following hardware forms: DSP (Digital Signal Processing), FPGA (Field-Programmable Gate Array), and PLA (Programmable Logic Array). Alternatively, processor 801 includes a main processor and a coprocessor. The main processor, also known as a CPU (Central Processing Unit), is used to process data in the wake-up state; the coprocessor is a low-power processor used to process data in the standby state.

[0235] In one possible implementation, the processor 801 integrates a GPU (Graphics Processing Unit), which is responsible for rendering and drawing the content that the display screen needs to show.

[0236] In one possible implementation, processor 801 also includes an AI (Artificial Intelligence) processor for handling computational operations related to machine learning.

[0237] The memory 802 includes one or more computer-readable storage media that are non-transitory. The memory 802 also includes high-speed random access memory and non-volatile memory, such as one or more disk storage devices or flash memory devices.

[0238] In one possible implementation, the non-transitory computer-readable storage medium in memory 802 is used to store at least one program code for execution by processor 801 to implement the remote vehicle fault handling method provided in the embodiments of this application.

[0239] In one possible implementation, the computer device 800 further includes a peripheral device interface 803 and at least one peripheral device. The processor 801, memory 802, and peripheral device interface 803 are connected via a bus or signal line. Each peripheral device is connected to the peripheral device interface 803 via a bus, signal line, or circuit board. The peripheral device includes at least one of the following: a radio frequency circuit 804, a display screen 805, a camera assembly 806, an audio circuit 807, a positioning assembly 808, and a power supply 809.

[0240] Peripheral device interface 803 is used to connect at least one I / O (Input / Output) related peripheral device to processor 801 and memory 802. In one possible implementation, processor 801, memory 802, and peripheral device interface 803 are integrated on the same chip or circuit board. In another possible implementation, any one or two of processor 801, memory 802, and peripheral device interface 803 are implemented on separate chips or circuit boards; this application is not limited to this.

[0241] Those skilled in the art will understand that Figure 8 The structure shown does not constitute a limitation on the computer device 800, and may include more or fewer components than shown, or combine certain components, or use different component arrangements.

[0242] Figure 9 This is a schematic diagram of the structure of a computer device provided in an embodiment of this application.

[0243] The computer 900 can be a server. The computer device 900 can vary considerably depending on its configuration or performance, including one or more Central Processing Units (CPUs) 901 and one or more memories 902. The memories 902 store at least one line of program code, which is loaded and executed by the processor 901 to implement the aforementioned remote vehicle fault handling method. Of course, the computer device 900 also has wired or wireless network interfaces, a keyboard, and input / output interfaces for input and output. The computer device 900 also includes other components for implementing the device's functions, which will not be elaborated upon here.

[0244] In an exemplary embodiment, a computer-readable storage medium is also provided, such as a memory including program code that can be executed by a processor in a computer device to complete the aforementioned remote handling method for vehicle malfunctions. For example, the computer-readable storage medium may be a read-only memory (ROM), a random access memory (RAM), a compact disc read-only memory (CD-ROM), magnetic tape, floppy disk, and optical data storage device, etc.

[0245] In an exemplary embodiment, a computer program product or computer program is also provided, which includes computer program code stored in a computer-readable storage medium. A processor of a computer device reads the computer program code from the computer-readable storage medium and executes the computer program code, causing the computer device to perform the aforementioned remote vehicle fault handling method.

[0246] Those skilled in the art will understand that all or part of the steps of the above embodiments can be implemented by hardware or by a program instructing related hardware. The program can be stored in a computer-readable storage medium, such as a read-only memory, a disk, or an optical disk.

[0247] The above description is merely an optional embodiment of this application and is not intended to limit this application. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the protection scope of this application.

Claims

1. A remote troubleshooting method for vehicle malfunctions, characterized in that, The method is applied to a remote fault handling system, the system including a cloud server and a vehicle; the method includes: The cloud server sends a remote diagnostic activation request to the vehicle and starts a first timer; wherein the first timer is used to record the duration of the cloud server's activation process. Upon receiving the remote diagnostics activation request, the vehicle performs a remote diagnostics activation condition check and starts a second timer and a third timer. The remote diagnostics activation condition check is used to check whether the current vehicle status meets the remote diagnostic requirements. The duration of the second timer is less than the pre-configured diagnostic timeout. The third timer is used to record the duration of the vehicle activation process. The vehicle sends a remote diagnostics activation response to the cloud server. If the remote diagnostics activation response indication is successful, the cloud server sends a remote diagnostics request to the vehicle. The vehicle obtains a diagnostic response based on the remote diagnostic request and sends the diagnostic response back to the cloud server. The cloud server generates a fault handling strategy by parsing the diagnostic response and then sends the fault handling strategy to the vehicle. When the remote diagnostics activation response indicates successful activation, the first timer and the third timer stop counting.

2. The method according to claim 1, characterized in that, The vehicle includes a remote diagnostic master node; the remote diagnostic enable condition check includes at least one of the following: The remote diagnostic master node checks the remaining power of the battery. The remote diagnostic master node performs a timeout check on the third timer; The remote diagnostic master node performs a task mutual exclusion check; wherein, the task mutual exclusion check is used to check whether there are other tasks with higher priority than the remote diagnostic task; or, the task mutual exclusion check is used to check whether there are other remote diagnostic tasks currently running.

3. The method according to claim 2, characterized in that, During the remote diagnostic activation condition check, if any activation condition is not met, the remote diagnostic activation fails, the vehicle terminates the check process, and the first timer and the third timer stop counting; or... In response to the timeout of the third timer, remote diagnostics failed to start; or, In response to the first timer timeout, remote diagnostics failed to start.

4. The method according to claim 1, characterized in that, The vehicle includes an onboard TBox and a remote diagnostic master node; the method further includes: The cloud server sends a remote diagnostic shutdown request using the first protocol format to the in-vehicle TBox; The vehicle-mounted TBox sends a remote diagnostics shutdown request using the second protocol format to the remote diagnostics master node; Upon receiving the remote diagnostic shutdown request using the second protocol format, the remote diagnostic master node controls the second timer to stop counting.

5. The method according to claim 4, characterized in that, The method further includes: In response to the second timer timeout, remote diagnostics are abnormally disabled; or, In response to the abnormal disconnection of the Transmission Control Protocol (TCP / TLS) link established between the cloud server and the remote diagnostic master node, the remote diagnostic system is abnormally shut down; or, In response to the TCP / TLS link established between the cloud server and the remote diagnostic master node being disconnected due to a continuous lack of packets, the remote diagnostic system is abnormally shut down; or, In response to an abnormal routing activation between the cloud server and the remote diagnostic master node, the remote diagnostic system is abnormally shut down.

6. The method according to claim 5, characterized in that, The method further includes: At the timeout of the second timer, in response to the absence of message transmission between the remote diagnostic master node and the cloud server, the remote diagnostic master node disconnects the TCP / TLS link; or, When the second timer expires, in response to the existence of message transmission between the remote diagnostic master node and the cloud server, the remote diagnostic master node disconnects the TCP / TLS link if preset conditions are met; The preset condition refers to the absence of an instruction from the cloud server within the first time period after the message transmission is completed.

7. The method according to claim 1, characterized in that, The vehicle includes an on-board TBox and a remote diagnostic master node; The cloud server sends a remote diagnostics activation request to the vehicle, including: The cloud server sends a remote diagnostic activation request using the first protocol format to the vehicle-mounted TBox; The vehicle-mounted TBox converts the remote diagnostic activation request from the first protocol format to the second protocol format. The vehicle-mounted TBox sends a remote diagnostics activation request using the second protocol format to the remote diagnostics master node.

8. The method according to claim 1, characterized in that, The vehicle includes a remote diagnostic master node and an in-vehicle diagnostic communication protocol DoIP node based on the Internet protocol format. The method further includes: The cloud server establishes a TCP / TLS link with the remote diagnostic master node and sends a route activation request to the remote diagnostic master node. The remote diagnostic master node performs route activation and sends a route activation response back to the cloud server. The remote diagnostic master node establishes a TCP / TLS link with the in-vehicle DoIP node and sends a route activation request to the in-vehicle DoIP node; The in-vehicle DoIP node performs route activation and sends a route activation response back to the remote diagnostic master node.

9. The method according to claim 1, characterized in that, The vehicle includes a remote diagnostic master node of the vehicle control data computing center and an in-vehicle diagnostic communication protocol DoIP node based on the Internet protocol format. The vehicle obtains a diagnostic response based on the remote diagnostic request, including: The remote diagnostic master node sends the remote diagnostic request to the in-vehicle DoIP node through the DoIP gateway; wherein, the remote diagnostic request includes the logical address of the destination node; The destination node obtains the diagnostic response after receiving the remote diagnostic request.

10. The method according to claim 9, characterized in that, When the in-vehicle DoIP node is a Vehicle Domain Controller (VIU), the method further includes: In response to the destination node being a downstream node of the VIU, the VIU performs protocol conversion on the remote diagnostic request using the DoIP protocol format according to the protocol type supported by the downstream node, to obtain the remote diagnostic request using the third protocol format. The third protocol is a protocol supported by the downstream node.

11. The method according to claim 1, characterized in that, In cases where changes to the vehicle controller's internal storage are required, the method further includes: The cloud server sends a user authorization request to the target terminal; The target terminal includes at least one of an in-vehicle terminal or a mobile terminal; the user authorization request is used to request permission to be granted within a second time period.

12. A remote fault handling system, characterized in that, The system includes a cloud server and vehicles; The cloud server is used to send a remote diagnostic activation request to the vehicle and start a first timer; wherein the first timer is used to record the duration of the cloud server's activation process. The vehicle is configured to perform a remote diagnostics activation condition check and start a second timer and a third timer after receiving the remote diagnostics activation request; wherein, the remote diagnostics activation condition check is used to check whether the current vehicle status meets the remote diagnostic requirements; the duration of the second timer is less than the pre-configured diagnostic time limit; the third timer is used to record the duration of the vehicle activation process; The vehicle is also used to send a remote diagnostic activation response to the cloud server; The cloud server is also used to send a remote diagnostic request to the vehicle when the remote diagnostic activation response indication is successfully activated. The vehicle is also configured to obtain a diagnostic response based on the remote diagnostic request and send the diagnostic response back to the cloud server; The cloud server is also used to generate a fault handling strategy by parsing the diagnostic response and to send the fault handling strategy to the vehicle; When the remote diagnostics activation response indicates successful activation, the first timer and the third timer stop counting.

13. A computer device, characterized in that, The device includes a processor and a memory, the memory storing at least one piece of program code, the at least one piece of program code being loaded and executed by the processor to implement the remote handling method for vehicle malfunctions as described in any one of claims 1 to 11.

14. A computer-readable storage medium, characterized in that, The storage medium stores at least one piece of program code, which is loaded and executed by a processor to implement the remote handling method for vehicle malfunctions as described in any one of claims 1 to 11.

Images