Vehicle remote diagnosis method and device, vehicle and server

Abstract

The invention provides a remote diagnosis method and device for a vehicle, the vehicle and a server. The method comprises the steps of receiving a remote diagnosis task sent by a first server under the condition that the first server determines that a vehicle owner allows remote diagnosis of the vehicle through a second server; and in response to the received remote diagnosis task sent by the first server, executing operation related to remote diagnosis. By using the method, the vehicle is remotely diagnosed under the condition that the user authorization is obtained, so that the safety of the vehicle and the user can be ensured in the remote diagnosis of the vehicle.

Description

Technical Field

[0001] The present application relates to the field of vehicle diagnosis technology, and more specifically, to a vehicle remote diagnosis method, a vehicle remote diagnosis device, a vehicle, and a server. Background Art

[0002] Remote diagnosis of vehicles may involve writing operations to the vehicle, which may cause security issues and threaten the safety of the vehicle and the user. How to ensure the safety of the vehicle and the user during remote diagnosis of the vehicle is a technical problem that needs to be solved. Summary of the invention

[0003] The present application provides a vehicle remote diagnosis method, a vehicle remote diagnosis device, a vehicle, and a server to ensure the safety of the vehicle and the user during the vehicle remote diagnosis.

[0004] In a first aspect, a remote diagnosis method for a vehicle is provided, which is executed by the vehicle, and comprises: receiving a remote diagnosis task sent by a first server when the first server determines through a second server that the owner allows remote diagnosis of the vehicle; and executing remote diagnosis-related operations in response to receiving the remote diagnosis task sent by the first server.

[0005] As a possible implementation manner, the method also includes: receiving a remote diagnosis authorization task from a third server; in response to the remote diagnosis authorization task, presenting inquiry information to the vehicle owner, the inquiry information being used to inquire whether the vehicle owner allows remote diagnosis of the vehicle; in response to the vehicle owner allowing remote diagnosis of the vehicle, sending an authorization result of the vehicle owner's consent to authorization to the third server, so that the third server synchronizes the authorization result to the second server.

[0006] As a possible implementation manner, the method also includes: before receiving the remote diagnostic task, receiving a wake-up instruction sent by the first server; in response to the wake-up instruction, controlling the vehicle to enter a power-on state; in response to the completion of the remote diagnostic task, controlling the vehicle to enter a power-off state.

[0007] As a possible implementation manner, the method further includes: transmitting remote diagnostic data to the first server; and in response to completion of the remote diagnostic task, clearing the remote diagnostic data cached by the vehicle.

[0008] As a possible implementation manner, the method further includes: synchronizing the authorization result to the handheld terminal of the vehicle owner through the third server; and / or receiving the authorization result corresponding to the handheld terminal through the third server.

[0009] In a second aspect, a remote diagnosis method for a vehicle is provided, characterized in that the method is executed by a third server, and the method includes: sending a remote diagnosis authorization task to the vehicle and / or the handheld terminal of the owner; receiving an authorization result sent by the vehicle and / or the handheld terminal, and the authorization result is used to indicate whether the owner allows remote diagnosis of the vehicle.

[0010] As a possible implementation manner, the method further includes: synchronizing the authorization result sent by the vehicle to the handheld terminal; and / or synchronizing the authorization result sent by the handheld terminal to the vehicle.

[0011] According to a third aspect, a remote diagnosis device for a vehicle is provided, characterized in that it includes: a receiving module for receiving a remote diagnosis task sent by a first server when the first server determines through a second server that the owner allows remote diagnosis of the vehicle; and a processing module for executing operations related to remote diagnosis in response to receiving the remote diagnosis task sent by the first server.

[0012] In a fourth aspect, a remote diagnosis device for a vehicle is provided, characterized in that it includes: a sending module for sending a remote diagnosis authorization task to the vehicle and / or the handheld terminal of the owner; a receiving module for receiving the authorization result sent by the vehicle and / or the handheld terminal, and the authorization result is used to indicate whether the owner allows remote diagnosis of the vehicle.

[0013] In a fifth aspect, a vehicle is provided, comprising the remote diagnostic device for the vehicle as described in the third aspect.

[0014] In a sixth aspect, a server is provided, wherein the server includes the remote diagnostic device for the vehicle as described in the fourth aspect.

[0015] According to a seventh aspect, a computer-readable storage medium is provided, on which a program code for executing the method according to the first aspect or the second aspect is stored.

[0016] According to an eighth aspect, a computer program product is provided, wherein the computer program product comprises a program code for executing the method according to the first aspect or the second aspect.

[0017] Before remote diagnosis of a vehicle is performed, the embodiment of the present application first determines whether the vehicle owner allows remote diagnosis of the vehicle. Only when the vehicle owner allows remote diagnosis of the vehicle, the remote diagnosis-related operations are performed on the vehicle. In this way, the safety of the vehicle and the user during the remote diagnosis process can be guaranteed. BRIEF DESCRIPTION OF THE DRAWINGS

[0018] In order to more clearly illustrate the technical solutions in the embodiments of the present application or the related technologies, the drawings required for use in the embodiments or the related technical descriptions are briefly introduced below. Obviously, the drawings described below are only some embodiments of the present application, and other drawings obtained by ordinary technicians in this field based on these drawings fall within the scope of the present application.

[0019] Figure 1 It is a schematic flow chart of a method for obtaining remote diagnostic data provided in the related art.

[0020] Figure 2 It is a schematic flowchart of a remote diagnosis method for a vehicle provided in one embodiment of the present application.

[0021] Figure 3 It is a schematic flowchart of querying authorization results provided in an embodiment of the present application.

[0022] Figure 4 It is a schematic flowchart of a remote diagnosis method for a vehicle provided in another embodiment of the present application.

[0023] Figure 5 This is an example diagram of a pop-up window provided in an embodiment of the present application.

[0024] Figure 6 It is a schematic flowchart of obtaining remote diagnosis authorization through a vehicle computer provided in an embodiment of the present application.

[0025] Figure 7 The present invention provides a schematic flowchart of obtaining remote diagnosis authorization through distribution.

[0026] Figure 8 It is a schematic flowchart of synchronizing authorization results provided in an embodiment of the present application.

[0027] Fig. 9 It is a schematic flowchart of synchronizing the authorization result of a mobile phone to a vehicle computer provided in an embodiment of the present application.

[0028] Fig.10 This is a schematic flowchart of remote wake-up provided in an embodiment of the present application.

[0029] Fig.11 It is a logical view of the interior of the cockpit during remote wake-up provided in an embodiment of the present application.

[0030] Fig.12 It is a schematic flowchart of remote debugging provided in an embodiment of the present application.

[0031] Fig.13 This is an example flow chart of the remote diagnosis method for a vehicle provided in an embodiment of the present application.

[0032] Fig.14 This is a structural example diagram of a remote diagnostic device for a vehicle provided in one embodiment of the present application.

[0033] Fig.15 This is a structural example diagram of a remote diagnostic device for a vehicle provided in another embodiment of the present application. DETAILED DESCRIPTION

[0034] The technical solutions in the embodiments of the present application will be described clearly and completely below in conjunction with the drawings in the embodiments of the present application. Obviously, the described embodiments are part of the embodiments of the present application, rather than all of the embodiments. All other embodiments obtained based on the embodiments in the present application belong to the scope of protection of the present application.

[0035] In the embodiments of the present application, words such as "exemplary" or "for example" are used to indicate examples, illustrations or descriptions. Any embodiment or design described as "exemplary" or "for example" in the embodiments of the present application should not be interpreted as being more preferred or more advantageous than other embodiments or designs. Specifically, the use of words such as "exemplary" or "for example" is intended to present related concepts in a specific way.

[0036] It should be understood that the specific embodiments described below are only used to explain the present application and are not used to limit the present application.

[0037] The embodiment of the present application can be applied to remote diagnosis of a vehicle. For ease of understanding, the remote diagnosis involved in the embodiment of the present application is first introduced.

[0038] Remote vehicle diagnosis is a technology that uses modern communication technology and computer network technology to achieve non-contact inspection of the vehicle's health status. This technology allows service centers or maintenance personnel to obtain vehicle data through the Internet or other data transmission methods when the vehicle is not on site, and analyze it to detect whether the vehicle has faults or potential problems.

[0039] Remote vehicle diagnosis usually includes one or more of the following aspects:

[0040] Data collection: Collect information through various sensors on the vehicle, such as engine temperature, oil pressure, battery voltage, etc.

[0041] Data transmission: The collected data is sent to a remote server via a wireless network (such as a cellular network).

[0042] Data analysis: Specialized software is used on the server side to analyze this data to determine whether the vehicle's status is normal and whether there are any possible faults.

[0043] Fault diagnosis and reporting: Based on the analysis results, the vehicle's problems are identified and a diagnostic report is generated. In addition, some maintenance suggestions or repair guides can also be provided.

[0044] Real-time monitoring: Remote diagnosis may also involve simultaneous monitoring of multiple vehicles, helping managers understand the working status of each vehicle and improve operational efficiency.

[0045] In addition to the above aspects, in order to provide more comprehensive remote diagnostic services, data writing may also be involved in the remote diagnosis process. For example, the remote diagnostic system may adjust relevant parameters of the vehicle, and such adjustments may involve data writing. For another example, remote diagnosis may also include updates to related firmware to correct known errors or improve performance, and such updates may involve data writing. Writing data to the vehicle may cause changes in the vehicle's configuration or performance, which may cause accidents and threaten the safety of the vehicle and users. Therefore, how to ensure the safety of the vehicle and users during remote diagnosis of the vehicle is a technical problem that needs to be solved.

[0046] In addition, from the above description, it can be seen that the remote diagnosis of the vehicle involves the collection of vehicle data. Some solutions for collecting vehicle data are proposed in the relevant technology. Figure 1 Provide explanation.

[0047] like Figure 1 As shown, in step S101, the vehicle data platform creates a signal collection task.

[0048] In step S102, the vehicle data platform issues a signal collection task.

[0049] In step S103, the signal collection task is pushed to all vehicles.

[0050] In step S104 , the vehicle is powered on.

[0051] In step S105, signal data is generated.

[0052] In step S106, the generated signal data is periodically saved.

[0053] In step S107, it is determined whether the saved data matches the collection task.

[0054] In step S108, if the saved data matches the acquisition task, the signal data is uploaded.

[0055] In step S109, if the saved data does not hit the collection task, the data is left in the car.

[0056] Through the above steps, vehicle-related data can be collected during the driving process. When a problem occurs with the vehicle, the data obtained through the above process can be retrieved to perform remote diagnosis on the vehicle. However, there are the following problems with remote diagnosis of vehicles using this data collection method.

[0057] The above data collection process is executed for all vehicles pushed to the signal collection task. The collected data is for a batch of vehicles of various types, and it is impossible to collect data for specific vehicle usage problems of a specific vehicle. If you want to use the data collected through the above data collection process to remotely diagnose a certain vehicle, it may be difficult to obtain data that is strongly related to the vehicle usage problems of the vehicle. This may make the diagnosis process more cumbersome and the diagnosis results less accurate.

[0058] In the above data collection process, as long as the vehicle is powered on, data will be acquired periodically. The entire data collection process is carried out without the user's perception, and there is no interaction with the user, so the user experience is not good enough.

[0059] In order to solve the above technical problems, an embodiment of the present application provides a remote diagnosis method for a vehicle. The method is executed by the vehicle, and the method includes: when the first server determines through the second server that the owner allows remote diagnosis of the vehicle, receiving the remote diagnosis task sent by the first server; in response to receiving the remote diagnosis task sent by the first server, performing remote diagnosis-related operations. Using the above method, before remote diagnosis of the vehicle is performed, it is first determined whether the owner allows remote diagnosis of the vehicle. Only when the owner allows remote diagnosis of the vehicle, remote diagnosis-related operations are performed on the vehicle. In this way, the safety of the vehicle and the user during the remote diagnosis process can be guaranteed.

[0060] Combine the following Figures 2 to 13 The remote diagnosis method of a vehicle provided in an embodiment of the present application is described in detail.

[0061] Figure 2 A schematic flowchart of a remote diagnosis method for a vehicle provided in an embodiment of the present application. Figure 2 The method is described from the perspective of the vehicle.

[0062] The embodiments of the present application do not specifically limit the purpose of the vehicle. The vehicles involved in the embodiments of the present application may be passenger cars, commercial vehicles, special vehicles, etc. Passenger cars may be vehicles used for personal or family travel, such as sedans, sport utility vehicles (SUVs), multi-purpose vehicles (MPVs), etc. Commercial vehicles may be vehicles used for commercial transportation or work, such as trucks, buses, vans, etc. Special vehicles may be vehicles with specific functions or uses, such as fire trucks, ambulances, police cars, engineering vehicles, etc. The embodiments of the present application do not specifically limit the power type of the vehicle. The vehicles involved in the embodiments of the present application may be electric vehicles, hybrid vehicles, plug-in hybrid vehicles, fuel cell vehicles, etc.

[0063] like Figure 2 As shown, the remote diagnosis method for a vehicle provided in an embodiment of the present application may include the following steps S201 and S202.

[0064] In step S201, when the first server determines through the second server that the vehicle owner allows remote diagnosis of the vehicle, the first server receives a remote diagnosis task sent by the first server.

[0065] The first server here can be used to send a remote diagnosis task to the vehicle. The first server can be a cloud server or a physical server. When the first server is a cloud server, the first server can be, for example, a cockpit service cloud server.

[0066] The second server here can be used to store the authorization result of the car owner. The second server can be a cloud server or a physical server. When the second server is a cloud server, the first server can be, for example, an intelligent diagnosis cloud server. The authorization result here is used to indicate whether the car owner allows remote diagnosis of the vehicle. The authorization result here can be the authorization result obtained through the authorization process described below. If the authorization result indicates that the car owner allows remote diagnosis of the vehicle, the subsequent remote diagnosis process can be carried out. If the authorization result indicates that the car owner does not allow remote diagnosis of the vehicle, the subsequent remote diagnosis process will not be carried out.

[0067] The first server may query the authorization result of the vehicle owner through the second server. That is, the first server may learn from the second server whether the vehicle owner allows remote diagnosis of the vehicle. Optionally, in some embodiments, the first server may query the authorization result from the second server through an interface. Optionally, in some embodiments, the first server may send a query instruction to the second server, and the second cloud server may send the authorization result to the first cloud server in response to the query instruction.

[0068] If the first server determines through the second server that the owner allows remote diagnosis of the vehicle, the first server may create a remote diagnosis task and send the remote diagnosis task to the vehicle. If the first server determines through the second server that the owner does not allow remote diagnosis of the vehicle, the first server may not create a remote diagnosis task. In other words, if the first server determines through the second server that the owner allows remote diagnosis of the vehicle, the vehicle may receive the remote diagnosis task sent by the first server.

[0069] The remote diagnosis task here may include one or more of the following: a log acquisition task and a debugging task. The log acquisition task may be, for example, a cockpit log acquisition task. The debugging task may be, for example, an Android debug bridge (ADB) debugging task.

[0070] In step S202, in response to receiving the remote diagnosis task sent by the first server, operations related to remote diagnosis are performed.

[0071] The remote diagnosis-related operations may include one or more of the following: receiving remote diagnosis-related instructions, transmitting remote diagnosis-related instructions, performing corresponding operations in response to remote diagnosis-related instructions, etc. Here, the "corresponding operations" may be, for example, capturing vehicle data or logs, sending vehicle data or logs, etc.

[0072] According to the above description, before remote diagnosis of the vehicle is performed, it is first determined whether the owner allows remote diagnosis of the vehicle. Only when the owner allows remote diagnosis of the vehicle can the remote diagnosis related operations be performed on the vehicle. In this way, the safety of the vehicle and the user can be guaranteed during the remote diagnosis process.

[0073] Steps S201 and S202 involve the first server obtaining the authorization result of the car owner through the second server, see below Figure 3 , and introduce the process of obtaining the authorization result with a specific example. In the following example, the first server is the cockpit service cloud server, and the second server is the intelligent diagnosis cloud server.

[0074] like Figure 3 As shown, in step S301, the operation and maintenance personnel initiate a remote diagnosis request to the cockpit service cloud server.

[0075] In step S302, the cockpit service cloud server sends an instruction to query the authorization result to the intelligent diagnosis cloud server.

[0076] In step S303, the intelligent diagnosis cloud server returns the authorization result to the cockpit service cloud server.

[0077] In step S304, if the authorization result is authorized, the cockpit service cloud server creates remote diagnosis tasks such as capturing logs and remote debugging, and sends the above remote diagnosis tasks to the intelligent diagnosis cloud server.

[0078] As mentioned above, the authorization result of the car owner can be obtained through the authorization process to determine whether the car owner allows remote diagnosis of the vehicle. The authorization process is described in detail below.

[0079] See also Figure 4 The authorization process of remote diagnosis in the embodiment of the present application may include the following steps S301 to S302.

[0080] In step S401, a remote diagnosis authorization task is received from a third server.

[0081] The third server here may be a server with different functions from the first server. The third server may have a remote data acquisition function. The third server may be a cloud server or a physical server. When the third server may be a cloud server, the third server may be, for example, a remote vehicle data collection (RVDC) cloud server. The remote diagnosis authorization task may be understood as a task requesting the owner (or user) to grant remote diagnosis operation authority. Optionally, in some embodiments, the vehicle may receive the remote diagnosis authorization task from the cloud server via a telematics service provider (TSP). "The vehicle receives a remote diagnosis authorization task from a third server" may include or be replaced by: the vehicle receives a remote diagnosis authorization task from a third server. The vehicle here may be understood as an in-vehicle infotainment system installed in the vehicle. The vehicle may receive a remote diagnosis authorization task via the vehicle APP.

[0082] In step S402 , in response to the remote diagnosis authorization task, query information is presented to the vehicle owner.

[0083] After the vehicle receives the remote diagnosis authorization task sent by the third server in step S401, it can present the inquiry information to the owner in response to the remote diagnosis authorization task. The inquiry information here is used to ask the owner whether to allow remote diagnosis of the vehicle. The inquiry information can be presented to the owner in a variety of ways. Optionally, in some embodiments, the inquiry information can be presented to the owner in a voice manner. For example, after receiving the remote diagnosis authorization task, the vehicle can play a voice prompt message to ask the user whether to allow remote diagnosis of the vehicle. Optionally, in other embodiments, the inquiry information can be presented to the owner in a visual manner. For example, after receiving the remote diagnosis authorization task, the vehicle can display a pop-up window on the screen of the vehicle and display the inquiry information on the pop-up window. After the owner learns the inquiry information, he can choose to allow remote diagnosis of the vehicle, or he can choose not to allow (refuse) remote diagnosis of the vehicle. If the owner chooses to allow remote diagnosis of the vehicle, the subsequent remote diagnosis process can be carried out. If the owner chooses not to allow remote diagnosis of the vehicle, the subsequent remote diagnosis process cannot be carried out.

[0084] Optionally, in some embodiments, an authorization validity period, or authorization duration, may be set for the remote diagnosis authorization task. In this case, "the vehicle owner allows remote diagnosis of the vehicle" may be replaced with: the vehicle owner allows remote diagnosis of the vehicle within the authorization validity period (or authorization duration). For example, the authorization validity period may be set to 24 hours.

[0085] Optionally, in some embodiments, when the vehicle is abnormally restarted, the authorization duration countdown is still valid. In other words, the period of vehicle abnormality is not counted into the authorization duration, and the authorization obtained before is still valid after the vehicle returns to normal.

[0086] In step S403, in response to the vehicle owner allowing remote diagnosis of the vehicle, an authorization result of the vehicle owner's consent to authorization is sent to the third server, so that the third server synchronizes the authorization result to the second server.

[0087] If the owner chooses to allow remote diagnosis of the vehicle after learning the inquiry information, the authorization result that the owner agrees to authorize can be sent to the third server. The vehicle can send the authorization result that the owner agrees to authorize to the third server through TSP, so that the third server synchronizes the authorization result to the second server. That is, in some implementations, the third server can synchronize the authorization result to the second server. In other words, the second server can obtain the authorization result from the third server.

[0088] Optionally, in some embodiments, after receiving the authorization result of the car owner's consent to authorization, the third server may save the authorization result of the car owner's consent to authorization on the third server.

[0089] Optionally, in some embodiments, the vehicle may also send an authorization result indicating that the vehicle owner disagrees with the authorization to the third server in response to the vehicle owner not allowing remote diagnosis of the vehicle. The third server may store the authorization result indicating that the vehicle owner disagrees with the authorization.

[0090] In step S402, it is mentioned that the inquiry information can be presented to the vehicle owner by displaying a pop-up window on the screen of the vehicle. The pop-up window here is used to ask the vehicle owner whether to allow remote diagnosis of the vehicle. In this case, the vehicle can receive the input information of the vehicle owner based on the pop-up window. The input information here is used to indicate whether the vehicle owner allows remote diagnosis of the vehicle.

[0091] The embodiments of the present application do not specifically limit the content in the pop-up window. The content in the pop-up window may include a statement asking the owner whether to allow remote diagnosis of the vehicle, such as "Apply for remote diagnosis of your vehicle, are you allowed?". The content in the pop-up window may also include prompt information to remind the owner of the matters needing attention during the remote diagnosis process. The prompt information may be, for example, "During the diagnosis process, the vehicle should not be driven to prevent potential risks." The above input information may be an option for the owner to choose in the pop-up window. The option may include a first option and a second option. The first option is used to indicate that the owner allows remote diagnosis of the vehicle, and the second option is used to indicate that the owner does not allow remote diagnosis of the vehicle. The first option may be, for example, "Confirm", "Allow", "Agree", etc. The second option may be, for example, "Reject", "Do not allow", "Disagree", etc. Figure 5 An example of a pop-up window is shown. After seeing the pop-up window, the owner can click the "Confirm" option if he allows remote diagnosis of the vehicle, or click the "Do not allow" option if he does not allow remote diagnosis of the vehicle. Obtaining the owner's authorization through a pop-up window can enhance the user's experience and sense of participation in the remote diagnosis process.

[0092] When a pop-up window is displayed on the screen of the vehicle, other pages besides the pop-up window may be displayed on the screen. The display priority of the pop-up window can be set to be higher than the display priority of other pages. "The display priority of the pop-up window is set to be higher than the display priority of other pages" can be understood as: when the pop-up window overlaps with other pages, the pop-up window is displayed in full first. Alternatively, "the display priority of the pop-up window is set to be higher than the display priority of other pages" can be understood as: when the pop-up window overlaps with other pages, the pop-up window covers other pages. The other pages here can be any page that can be displayed on the vehicle screen, such as a navigation page, a page for playing music, a page for playing movies, etc. In other words, no matter what page is currently displayed on the vehicle screen, the pop-up window can appear on that page. In this way, it can be ensured that the inquiry information can be seen by the car owner, so that the car owner's authorization can be obtained as soon as possible, so as to solve the car use problem as soon as possible.

[0093] Optionally, in some embodiments, after receiving the input information from the vehicle owner based on the pop-up window, the pop-up window can be closed. For example, when the vehicle owner clicks on the option on the pop-up window indicating permission for remote diagnosis of the vehicle, the pop-up window can be closed and the subsequent process can be continued.

[0094] Optionally, in some embodiments, in response to not receiving the owner's input information within a first preset time period, the pop-up window can be closed. The first preset time period here can be a time period set by default for the vehicle, or it can be a time period set by the owner. The first preset time period can be, for example, 10 seconds. If the owner does not click on the option on the pop-up window within 10 seconds, the pop-up window can be closed. As mentioned above, the display priority of the pop-up window can be set to be higher than the display priority of other pages. In some cases, when the pop-up window appears on other pages, it may be inconvenient for the owner to click manually, but at the same time, it is necessary to obtain relevant information on other pages. By setting the first preset time period, it can be prevented that the pop-up window is displayed for too long and affects the owner's acquisition of information on other pages.

[0095] Optionally, in some embodiments, in response to not receiving the owner's input information within a first preset time period, the pop-up window can be stored in a message box. The message box here can be used to store data related to user interaction during the operation of the vehicle. In some cases, when the pop-up window pops up, the owner may be dealing with other things and has no time to click on the pop-up window. After the first preset time period, if the owner has not clicked on the pop-up window, the pop-up window will be closed. By storing the pop-up window in the message box, if the owner wants to start the remote diagnosis process after the pop-up window is closed, the pop-up window can be retrieved from the message box, and the option to allow remote diagnosis of the vehicle can be selected by clicking on the pop-up window.

[0096] The following is a detailed description of the process of the third server initiating authorization through the vehicle computer with a specific example. In the following example, the third server is RVDC SERVER.

[0097] like Figure 6 As shown, in step S601, the RVDC SERVER sends a diagnosis authorization task to the RVDC MASTER in the digital cockpithead unit (DHU).

[0098] In step S602, the RVDC MASTER transmits the diagnosis authorization task to the over-the-air proxy (OTA PROXY) in the DHU in a transparent manner.

[0099] In step S603, OTA PROXY identifies whether the received task is an authorized task, and when it is identified that the received task is an authorized task, it sends the authorized diagnostic task to the vehicle setting (CAR SETTING) and notifies CAR SETTING to pop up a window.

[0100] In step S604, the CAR SETTING pop-up window appears. Figure 5 The pop-up window shown above requests the car owner's authorization. The car owner clicks the button on the pop-up window to choose whether to allow remote diagnosis of the vehicle.

[0101] In step S605, CAR SETTING saves the user's authorization result. CAR SETTING can save (or record) the authorization result by embedding. The authorization result is an enumeration value. For example, the authorization result can be "the vehicle confirms the authorization" or "the vehicle cancels the authorization". If the authorization result is "the vehicle confirms the authorization", CAR SETTING can also save the authorization duration.

[0102] In step S606, CAR SETTING sends the authorization result to OTA PROXY. OTA PROXY can save the authorization result. For example, OTA PROXY can save the authorization result by embedding a point.

[0103] In step S607, OTA PROXY sends the authorization result to RVDC MASTER.

[0104] In step S608, the RVDC MASTER sends the authorization result to the RVDC SERVER.

[0105] The above describes how the third server obtains the remote diagnosis authorization result through the vehicle. Optionally, in some embodiments, the third server can also obtain the remote diagnosis authorization result through the car owner's handheld terminal. The third server can send the above remote diagnosis authorization task to the car owner's handheld terminal. In response to the above remote diagnosis authorization task, the handheld terminal can present an inquiry message to the car owner to inquire whether the car owner allows remote diagnosis of the vehicle. In response to the car owner allowing remote diagnosis of the vehicle, the handheld terminal can send the authorization result of the car owner's consent to authorization to the third server. The third server can save the authorization result of the car owner's consent to authorization. The handheld terminal can also send the authorization result of the car owner's disagreement to authorization to the third server in response to the car owner not allowing remote diagnosis of the vehicle. The third server can save the authorization result of the car owner's disagreement to authorization.

[0106] The embodiments of the present application do not specifically limit the type of handheld terminal. The handheld terminal here can be, for example, a mobile phone, a tablet computer, a watch, a bracelet, etc. Remote authorization can be achieved by sending a remote diagnosis authorization task to the car owner's handheld terminal. In other words, even if the car owner is not in the car, the remote diagnosis can be authorized through the handheld terminal to facilitate the subsequent execution of remote diagnosis operations. The handheld terminal can receive the remote diagnosis authorization task sent by the third server through TSP. When the third server sends a remote diagnosis authorization task to both the vehicle and the car owner's handheld terminal through TSP, it can be understood that TSP distributes the remote diagnosis authorization task to the vehicle and the handheld terminal. The following is combined with Figure 7 Detailed explanation of how to distribute remote diagnosis authorization tasks through TSP. In the following example, the third server is the RVDC cloud and the handheld terminal is a mobile phone.

[0107] like Figure 7 As shown, in step S701, the remote diagnosis process is started.

[0108] In step S702, the RVDC cloud initiates a remote diagnosis authorization task and sends the remote diagnosis authorization task to the TSP.

[0109] In step S703, the TSP sends the remote diagnosis authorization task to the vehicle APP.

[0110] In step S704, the TSP sends the remote diagnosis authorization task to the APP message center of the car owner's mobile phone.

[0111] In step S705, the mobile phone APP message center pushes the remote diagnosis authorization task to the mobile phone APP.

[0112] In step S706, the user performs authorization operations on the vehicle APP or the mobile phone APP.

[0113] As mentioned above, the vehicle can send an authorization result that the owner agrees to authorize to a third server in response to the owner allowing remote diagnosis of the vehicle. The vehicle can also send an authorization result that the owner disagrees to authorize to a third server in response to the owner not allowing remote diagnosis of the vehicle. Optionally, in some embodiments, the third server can send the authorization result of the vehicle to the owner's handheld terminal. After receiving the authorization result of the vehicle, the handheld terminal can save the authorization result of the vehicle in the handheld terminal. In other words, the authorization result of the vehicle can be synchronized to the owner's handheld terminal through the third server. The authorization result of the vehicle is an enumeration value. For example, the authorization result can be "mobile phone confirms authorization" or "mobile phone cancels authorization."

[0114] As mentioned above, the handheld terminal can send an authorization result that the car owner agrees to authorize to a third server in response to the car owner allowing remote diagnosis of the vehicle. The handheld terminal can also send an authorization result that the car owner disagrees to authorize to a third server in response to the car owner not allowing remote diagnosis of the vehicle. Optionally, in some implementations, the third server can send the authorization result sent by the handheld terminal to the vehicle. After receiving the authorization result from the mobile phone, the vehicle can save the authorization result of the mobile phone in the vehicle. In other words, the authorization result corresponding to the handheld terminal can be synchronized to the vehicle through the third server. The authorization result of the mobile phone is an enumeration value. For example, the authorization result can be "mobile phone confirms authorization" or "mobile phone cancels authorization."

[0115] Optionally, in some embodiments, when the authorization result of the mobile phone indicates that the owner authorizes (permits) remote diagnosis, the authorization validity period starts at the moment when the vehicle receives the authorization result of the mobile phone. For example, under normal circumstances, the vehicle computer should receive the authorization result of the owner's consent to authorization at the first moment, and the first moment is used as the starting moment of the authorization validity period. However, due to a problem in the network between the mobile phone and the vehicle computer, the vehicle computer receives the authorization result of the owner's consent to authorization at the second moment. In this case, the second moment is used as the starting moment of the authorization validity period.

[0116] According to the above description, the third server can send the remote diagnosis authorization task to both the vehicle and the owner's handheld terminal. In this case, if the vehicle computer obtains the authorization result first, the authorization result obtained by the vehicle computer can be synchronized to the owner's handheld terminal. If the handheld terminal obtains the authorization result first, the authorization result obtained by the handheld terminal can be synchronized to the vehicle computer. Figure 8 Provide explanation.

[0117] like Figure 8 As shown by the clockwise arrow in the figure, if the car owner's mobile phone obtains the authorization result first, the car owner's mobile phone will send the authorization result to the RVDC cloud. The RVDC cloud will save the authorization result obtained from the mobile phone and synchronize the authorization result to the car computer. Figure 8 As shown by the counterclockwise arrow in the figure, if the vehicle computer obtains the authorization result first, the vehicle computer will send the authorization result to the RVDC cloud. The RVDC cloud will save the authorization result obtained from the vehicle computer and synchronize the authorization result to the car owner's mobile phone.

[0118] As a more specific example, the following combines Fig. 9 This section describes in detail how to synchronize the authorization results of the handheld terminal to the vehicle. In the following example, the handheld terminal is a mobile phone and the third server is the RVDC SERVER.

[0119] like Fig. 9As shown, in step S901, the RVDC SERVER sends the authorization result of the mobile phone to the RVDC MASTER.

[0120] In step S902, RVDC MASTER sends the authorization result of the mobile phone to OTA PROXY in a transparent manner.

[0121] In step S903, OTA PROXY sends the authorization result of the mobile phone to the message box in the form of a notification.

[0122] In step S904, the message box displays a notification with the content "Mobile phone has been authorized".

[0123] In step S905, the authorization result of the mobile phone is saved in the message box in a buried manner.

[0124] In the above example, the authorization validity period starts from the moment when RVDC MASTER receives the authorization result from the mobile phone.

[0125] As mentioned above, in step S202, the vehicle may perform remote diagnosis-related operations in response to the remote diagnosis task sent by the first server.

[0126] Optionally, in some embodiments, before receiving the above-mentioned remote diagnostic task, the vehicle may also receive a wake-up instruction sent by the first server. The vehicle may enter a power-on state in response to the wake-up instruction, and enter a power-off state in response to the completion of the remote diagnostic task. That is, before the first server sends a remote diagnostic task to the vehicle, it may also send a wake-up instruction to the vehicle to control the vehicle to enter a power-on state. The first server may also control the vehicle to enter a power-off state in response to the completion of the remote diagnostic task. While the vehicle is in the power-on state, a timeout mechanism may be executed. For example, a timeout period may be set, and when the vehicle is in the power-on state for longer than the timeout period, the vehicle enters a power-off state regardless of whether the remote diagnostic task is completed. See below. Fig.10 and Fig.11 , and is described in detail with reference to specific examples. In the following example, the first server is a cockpit service cloud server.

[0127] Fig.10 A flow chart of a first server remotely waking up a vehicle is shown.

[0128] In step S1001, the operation and maintenance personnel send a wake-up command to the cockpit service cloud server.

[0129] In step S1002, the cockpit service cloud server sends a vehicle computer wake-up instruction to the TSP.

[0130] In step S1003, TSP sends the wake-up command to the telematics & connectivity antenna module (TCAM) by transparent transmission. TCAM wakes up the vehicle by sending a wake-up command (IPWAKEUP) through the IP address based on the virtual function cluster-partial network cluster (VFC-PNC) technology. At the same time, DHU controls the high voltage of the whole vehicle through the vehicle mode management (VMM) technology. During the high voltage period, the driver information module (DIM) screen, cockpit display system (CDS) screen and other screens are turned off.

[0131] In step S1004, the TCAM sends the wake-up result to the TSP.

[0132] In step S1005, the TSP sends the wake-up result to the cockpit service cloud server.

[0133] In step S1006, the operation and maintenance personnel confirm that the vehicle computer has been awakened, create a log task and a debugging task, and send the log task and the debugging task to the TSP for log collection. After the log upload is completed, the TCAM and DHU enter the dormant state.

[0134] During log collection, a 45-minute timeout mechanism is implemented. If the log upload cannot be completed within 45 minutes or the vehicle's three electric systems cannot receive the notification that the log upload is completed, the TCAM and DHU automatically enter the sleep state.

[0135] Fig.11 An example diagram of the logic inside the cockpit during the remote wake-up and remote log collection process is shown.

[0136] like Fig.11As shown, the cockpit service cloud server can send a remote wake-up command to the convenience subsystem of TCAM through TSP. The convenience subsystem notifies DHU to turn on high voltage for the whole vehicle through the Internet Protocol Control Protocol (IPCP) message. DHU passes the remote wake-up command to the log upload service (UploadSvc) through the middleware (including IPCP protocol stack, IPCP service, and adaptive service), where the IPCP service and the IPCP protocol stack are connected through the Java native interface (Java native interface, JNI). The log upload service receives the wake-up command and implements the logic of turning on high voltage for the whole vehicle. The unified diagnostic service (UDS) client notifies the vehicle's three-electric module to turn on high voltage. After the high voltage is turned on, the remote log collection command is received according to the original process, and the collection task is uploaded. After the log upload task is completed, the three-electric module is notified to turn off high voltage through the UDS client.

[0137] As can be seen from the foregoing description, during the remote diagnosis process, the vehicle may generate remote diagnosis data. The remote diagnosis data here may be, for example, instructions for controlling the hardware or software in the vehicle to perform related operations, intermediate data generated by the hardware or software in the vehicle during the execution of related operations, etc.

[0138] Optionally, in some embodiments, the vehicle may transmit the remote diagnostic data to the first server. After receiving the remote diagnostic data, the first server may save the remote diagnostic data. In this way, if the detailed process of the remote diagnosis is to be known later, the remote diagnostic data may be queried through the first server.

[0139] Optionally, in some embodiments, the remote diagnosis data cached in the vehicle can be cleared in response to the completion of the remote diagnosis task. In this way, after the remote diagnosis is completed, there will be no residual data generated by the remote diagnosis in the vehicle, which can leave a clean vehicle environment for the user and achieve "traceless" diagnosis.

[0140] As mentioned above, the remote diagnosis task may include a remote debugging task. The remote debugging task may be performed by the first server. Fig.12 This section describes the remote debugging process.

[0141] like Fig.12 As shown, in step S1201, the maintenance personnel initiate remote debugging to the cockpit service cloud server.

[0142] In step S1202, the cockpit service cloud server creates a socket notification and sends the socket notification to the message queuing telemetry transport (MQTT) message center of the cockpit system on chip (SOC) to establish communication with the cockpit SOC.

[0143] In step S1203, the MQTT message center sends a socket message to the log (LOG) subsystem of the cockpit SOC to inform the LOG subsystem which logs need to be uploaded to the cockpit service cloud server.

[0144] In step S1204, the cockpit service cloud server and the LOG subsystem complete command interaction through the socket channel to achieve remote debugging.

[0145] Through the above-mentioned remote log collection process and remote debugging process, data collection and related operations can be performed on vehicle usage issues, which is highly targeted, thereby improving the efficiency of remote diagnosis.

[0146] Optionally, in some embodiments, the remote diagnosis method for a vehicle provided in the embodiments of the present application further includes: before controlling the vehicle to enter a power-off state, receiving first information sent by a first server. The first information may include feedback information and / or indication information. The feedback information may be used to feedback the result of the remote diagnosis to the owner. The owner may learn the cause of the abnormality or failure of the vehicle based on the result of the remote diagnosis. The indication information may be used to provide operation suggestions to the owner. The owner may perform relevant operations based on the operation suggestions to solve the problem of using the vehicle.

[0147] Through the above method, after the remote diagnosis task is completed, the results of the remote diagnosis can be informed to the car owner through interaction with the car owner, and operation instructions can be provided to the car owner based on the results of the remote diagnosis. The car owner can perform relevant operations according to the operation instructions to solve the car problem. In this way, the car owner can obtain information related to the remote diagnosis in a timely manner and personally participate in solving the car problem, which can make the car owner have a strong sense of participation in the remote diagnosis process.

[0148] Combination of the above Figures 2 to 12 The accompanying drawings describe in detail the various processes involved in the application embodiment. Fig.13 The overall process of the remote diagnosis method for a vehicle provided in an embodiment of the present application is described in detail.

[0149] like Fig.13 As shown, in step S1301, the user discovers a problem with the vehicle.

[0150] In step S1302, the user opens the remote diagnosis process through the vehicle settings, or provides feedback to after-sales personnel to request remote diagnosis.

[0151] In step S1303, a remote diagnosis request is initiated.

[0152] In step S1304, the user is asked whether to authorize remote diagnosis. If the user does not authorize, remote diagnosis cannot be performed.

[0153] In step S1305, if the user authorizes, the authorization result is received and the authorization validity period is saved for 24 hours.

[0154] In step S1306, the vehicle is powered on by remote control.

[0155] In step S1307, a diagnostic instruction is written to the vehicle.

[0156] In step S1308, the diagnosis instruction is executed.

[0157] In step S1309, the vehicle generates diagnostic data.

[0158] In step S1310, the diagnostic data is uploaded.

[0159] In step S1311, the vehicle use problem is diagnosed based on the diagnostic data.

[0160] In step S1312, the solution to the vehicle usage problem is fed back to the customer.

[0161] In step S1313, the data generated during the diagnosis process is deleted.

[0162] In step S1314, the vehicle is powered off by remote control. When the authorization validity period expires, there is no authority to initiate remote diagnosis.

[0163] Combination of the above Figures 1 to 13 , describes in detail an embodiment of the remote diagnosis method of a vehicle provided by the present application. The following describes in detail an embodiment of the device of the present application. It should be understood that the description of the device embodiment corresponds to the description of the method embodiment. Therefore, the part not described in detail can refer to the description of the previous method embodiment.

[0164] The embodiment of the present application also provides a remote diagnostic device 1400 for a vehicle. Fig.14 FIG. 1 shows a schematic block diagram of a remote diagnostic device 1400 for a vehicle provided in an embodiment of the present application. Fig.14 As shown, the device 1400 includes a receiving module 1410 and a processing module 1420 .

[0165] The receiving module 1410 is used to receive the remote diagnosis task sent by the first server when the first server determines through the second server that the vehicle owner allows remote diagnosis of the vehicle.

[0166] The processing module 1420 is configured to execute operations related to remote diagnosis in response to receiving the remote diagnosis task sent by the first server.

[0167] The embodiment of the present application also provides a remote diagnostic device 1500 for a vehicle. Fig.15 FIG. 1 is a schematic block diagram of a remote diagnostic device 1500 for a vehicle provided in an embodiment of the present application. Fig.15 As shown, the device 1500 includes a sending module 1510 and a receiving module 1520 .

[0168] The sending module 1510 is used to send the remote diagnosis authorization task to the vehicle and / or the handheld terminal of the vehicle owner.

[0169] The receiving module 1520 is used to receive the authorization result sent by the vehicle and / or the handheld terminal, and the authorization result is used to indicate whether the vehicle owner allows remote diagnosis of the vehicle.

[0170] The embodiment of the present application further provides a vehicle, which includes the vehicle remote diagnosis device 1300 described above.

[0171] The embodiment of the present application further provides a server, which includes the vehicle remote diagnosis device 1400 mentioned above.

[0172] The embodiment of the present application further provides a computer-readable storage medium having program codes stored thereon, and the program codes can be used to execute the remote diagnosis method of a vehicle in any of the above embodiments.

[0173] The embodiment of the present application further provides a computer program product, which includes program code for executing the remote diagnosis method of a vehicle in any of the above embodiments.

[0174] It should be understood that in the embodiment of the present application, determining B based on A does not mean determining B only based on A, but B can also be determined based on A and / or other information.

[0175] It should be understood that in the embodiment of the present application, "B corresponding to A" means that B is associated with A, and B can be determined according to A. However, it should also be understood that determining B according to A does not mean determining B only according to A, and B can also be determined according to A and / or other information.

[0176] It should be understood that the term "and / or" in this article is only a description of the association relationship of the associated objects, indicating that there can be three relationships. For example, A and / or B can represent: A exists alone, A and B exist at the same time, and B exists alone. In addition, the character " / " in this article generally indicates that the associated objects before and after are in an "or" relationship.

[0177] It should be understood that in the various embodiments of the present application, the size of the serial numbers of the above-mentioned processes does not mean the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of the present application.

[0178] In the several embodiments provided in the present application, it should be understood that the disclosed systems, devices and methods can be implemented in other ways. For example, the device embodiments described above are only schematic. For example, the division of units is only a logical function division. There may be other division methods in actual implementation. For example, multiple units or components can be combined or integrated into another system, or some features can be ignored or not executed. Another point is that the mutual coupling or direct coupling or communication connection shown or discussed can be through some interfaces, indirect coupling or communication connection of devices or units, which can be electrical, mechanical or other forms.

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

[0180] In addition, each functional unit in each embodiment of the present application may be integrated into one processing unit, or each unit may exist physically separately, or two or more units may be integrated into one unit.

[0181] In the above embodiments, it can be implemented in whole or in part by software, hardware, firmware or any combination thereof. When implemented using software, it can be implemented in whole or in part in the form of a computer program product. The computer program product includes one or more computer instructions. When loading and executing computer program instructions on a computer, the process or function according to the embodiment of the present application is generated in whole or in part. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable devices. The computer instructions can be stored in a computer-readable storage medium, or transmitted from one computer-readable storage medium to another computer-readable storage medium. For example, the computer instructions can be transmitted from a website site, a computer, a server or a data center by wired (e.g., coaxial cable, optical fiber, digital subscriber line (digital subscriber line, DSL)) or wireless (e.g., infrared, wireless, microwave, etc.) mode to another website site, computer, server or data center. The computer-readable storage medium can be any available medium that a computer can read or a data storage device such as a server, a data center, etc. that contains one or more available media integrated. Available media may be magnetic media (eg, floppy disks, hard disks, magnetic tapes), optical media (eg, digital video discs (DVD)), or semiconductor media (eg, solid state disks (SSD)).

[0182] The above are only specific implementations of the present application, but the protection scope of the present application is not limited thereto. Any technician familiar with the technical field can easily think of changes or substitutions within the technical scope disclosed in the present application, which should be included in the protection scope of the present application. Therefore, the protection scope of the present application should be based on the protection scope of the claims.

Claims

1. A remote diagnosis method for a vehicle, characterized in that: The method is performed by the vehicle, and comprises: When the first server determines through the second server that the vehicle owner allows remote diagnosis of the vehicle, receiving a remote diagnosis task sent by the first server; In response to receiving the remote diagnosis task sent by the first server, performing operations related to remote diagnosis.

2. The method according to claim 1, characterized in that: The method is performed by the vehicle, and the method further comprises: receiving a remote diagnosis authorization task from a third server; In response to the remote diagnosis authorization task, presenting inquiry information to the vehicle owner, the inquiry information being used to inquire whether the vehicle owner allows remote diagnosis of the vehicle; In response to the vehicle owner allowing remote diagnosis of the vehicle, an authorization result of the vehicle owner's consent to authorization is sent to the third server, so that the third server synchronizes the authorization result to the second server.

3. The method according to claim 1 or 2, characterized in that: The method further comprises: Before receiving the remote diagnosis task, receiving a wake-up instruction sent by the first server; In response to the wake-up instruction, controlling the vehicle to enter a power-on state; In response to the remote diagnosis task being completed, the vehicle is controlled to enter a power-off state.

4. The method according to claim 1 or 2, characterized in that: The method further comprises: transmitting remote diagnostic data to the first server; In response to the remote diagnosis task being completed, the remote diagnosis data cached by the vehicle is cleared.

5. The method according to claim 1 or 2, characterized in that: The method further comprises: Synchronizing the authorization result to the handheld terminal of the vehicle owner through the third server; and / or, The authorization result corresponding to the handheld terminal is received through the third server.

6. A remote diagnosis method for a vehicle, characterized in that: The method is performed by a third server, and includes: Sending a remote diagnosis authorization task to the vehicle and / or the owner's handheld terminal; An authorization result sent by the vehicle and / or the handheld terminal is received, where the authorization result is used to indicate whether the vehicle owner allows remote diagnosis of the vehicle.

7. The method according to claim 6, characterized in that The method further comprises: synchronizing the authorization result sent by the vehicle to the handheld terminal; and / or The authorization result sent by the handheld terminal is synchronized to the vehicle.

8. A remote diagnostic device for a vehicle, characterized in that: include: A receiving module, configured to receive a remote diagnosis task sent by the first server when the first server determines through the second server that the vehicle owner allows remote diagnosis of the vehicle; The processing module is used to execute operations related to remote diagnosis in response to receiving the remote diagnosis task sent by the first server.

9. A remote diagnostic device for a vehicle, characterized in that: include: A sending module, used for sending a remote diagnosis authorization task to a handheld terminal of a vehicle and / or a vehicle owner; The receiving module is used to receive the authorization result sent by the vehicle and / or the handheld terminal, and the authorization result is used to indicate whether the vehicle owner allows remote diagnosis of the vehicle.

10. A vehicle, characterized in that: include: The remote diagnostic device for a vehicle as claimed in claim 8.

11. A server, characterized in that: include: The remote diagnostic device for a vehicle as claimed in claim 9.

Images