Vehicle remote diagnosis method and system, server and storage medium

Abstract

The invention relates to the technical field of vehicle diagnosis, and discloses a vehicle remote diagnosis method and system, a server and a storage medium, and the method comprises the steps: transmitting a target order issuing request to a pre-trained remote diagnosis model in response to the target order issuing request, so as to enable the remote diagnosis model to output a target diagnosis keyword according to the target order issuing request; wherein the remote diagnosis model is obtained by training a large model based on a plurality of training data; each training data comprises a training order sending request and a corresponding output result; and determining a corresponding target configuration file path based on the target diagnosis keyword, and sending the target configuration file path and the target diagnosis keyword to the client, so that the client generates a remote diagnosis request based on the target configuration file path and the target diagnosis keyword. Natural language processing is realized through the pre-training model, so that a user can accurately initiate a remote diagnosis request without professional knowledge.

Description

Technical Field

[0001] The present application relates to the field of vehicle diagnosis technology, and in particular to a vehicle remote diagnosis method, system, server and storage medium. Background Art

[0002] The core architecture of the current remote diagnosis solution is to transmit the client (C-end) vehicle data to the service provider (B-end) in real time through the network, and the B-end service provider uses professional testing equipment to diagnose the C-end vehicle.

[0003] In existing remote diagnostic systems, order release modes are primarily categorized as smart and manual. Smart mode often collects a significant amount of unnecessary vehicle data, leading to the transmission of a significant amount of non-essential information to the customer end. This not only consumes valuable network bandwidth but also impacts the data transmission efficiency of key diagnostic modules, potentially leading to diagnostic anomalies such as system scan failures. Manual mode, however, suffers from numerous configuration files, making manual selections often leading to confusion, incorrect selections, and inefficiencies. Summary of the Invention

[0004] In view of this, embodiments of the present application provide a vehicle remote diagnosis method, system, server, and storage medium.

[0005] In a first aspect, an embodiment of the present application provides a vehicle remote diagnosis method, comprising:

[0006] In response to a target order request, the target order request is transmitted to a pre-trained remote diagnosis model, so that the remote diagnosis model outputs a target diagnosis keyword according to the target order request; wherein the remote diagnosis model is obtained by training a large model based on a plurality of training data; each training data includes a training order request and a corresponding output result;

[0007] A corresponding target configuration file path is determined based on the target diagnosis keyword, and the target configuration file path and the target diagnosis keyword are sent to the client, so that the client generates a remote diagnosis request based on the target configuration file path and the target diagnosis keyword.

[0008] In an optional embodiment, the training ticket request is a vehicle failure problem described in natural language;

[0009] The output includes make, model, year, and features.

[0010] In an optional embodiment, the training ticket issuance request includes vehicle fault questions asked by the user in the past and vehicle fault questions formed by randomly combining the brand, the model, the year and the function;

[0011] In an optional embodiment, training the large model based on the plurality of training data to obtain the remote diagnosis model includes:

[0012] Expanding the training order issuance request of each training data to form order issuance requests in multiple contexts corresponding to each training order issuance request, and using the order issuance request in each context and the corresponding output result as a set of training data;

[0013] Each set of training data is input into the large model for training until the error between the output diagnostic keyword and the corresponding output result reaches a preset cutoff condition, thereby obtaining the remote diagnostic model; wherein the diagnostic keywords include brand, model, year and function.

[0014] In an optional implementation, determining the corresponding target configuration file path based on the target diagnosis keyword includes:

[0015] The target configuration file path is determined according to the target diagnosis keyword in combination with a mapping relationship between the diagnosis keyword and the configuration file path.

[0016] In a second aspect, an embodiment of the present application provides a vehicle remote diagnosis system, a client, a web server, and a large model server;

[0017] The web server is used to send the received target order request to the large model server;

[0018] The large model server is configured to receive the target order request and enable the pre-trained remote diagnosis model to output a diagnosis keyword based on the target order request; wherein the remote diagnosis model is obtained by training the large model based on a plurality of training data; each of the training data includes a training order request and a corresponding output result;

[0019] The large model server is further configured to send the target diagnosis keyword to the web server;

[0020] The web server is further configured to determine a corresponding target configuration file path based on the target diagnosis keyword, and send the target configuration file path and the diagnosis keyword to the client, so that the client generates a remote diagnosis request based on the target configuration file path and the target diagnosis keyword.

[0021] In an optional implementation manner, the client is further configured to initiate the target order issuance request, and encapsulate the target order issuance request and transmit it to the web server.

[0022] In an optional embodiment, the web server includes a first interface; the large model server includes a second interface;

[0023] The web server receives the target order request through the first interface, and forwards the target order request to the second interface of the large model server through an internal tunnel;

[0024] The large model server receives the target order request through the second interface, and after the remote diagnosis model outputs the target diagnosis keyword, sends the target diagnosis keyword to the web server through the second interface.

[0025] In a third aspect, an embodiment of the present application provides a server, which includes a processor and a memory, wherein the memory stores a computer program, and the processor is used to execute the computer program to implement the vehicle remote diagnosis method described in the aforementioned embodiment.

[0026] In a fourth aspect, an embodiment of the present application provides a computer-readable storage medium storing a computer program. When the computer program is executed on a processor, it implements the vehicle remote diagnosis method according to the aforementioned embodiment.

[0027] The embodiments of the present application have the following beneficial effects: The present application processes order issuance requests through a pre-trained remote diagnosis model to obtain target diagnostic keywords, which can then be directly matched to the corresponding target configuration file path. In this way, when a user submits a target order issuance request, they only need to express it in natural language. The pre-trained remote diagnosis model then infers and identifies the user's target order issuance request to obtain the accurate target diagnostic keywords, and then obtain the target configuration file path. This allows the user to correctly initiate a remote diagnosis request without requiring specialized vehicle diagnosis knowledge. BRIEF DESCRIPTION OF THE DRAWINGS

[0028] In order to more clearly illustrate the technical solutions of the embodiments of the present application, the following is a brief introduction to the drawings required for use in the embodiments. It should be understood that the following drawings only show certain embodiments of the present application and therefore should not be regarded as limiting the scope. For ordinary technicians in this field, other relevant drawings can be obtained based on these drawings without creative work.

[0029] Figure 1 A schematic structural diagram of a vehicle remote diagnostic system according to an embodiment of the present application is shown;

[0030] Figure 2 A schematic diagram of the remote diagnosis model training process flow in an embodiment of the present application is shown;

[0031] Figure 3 A flow chart of a vehicle remote diagnosis method according to an embodiment of the present application is shown. DETAILED DESCRIPTION

[0032] 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 only part of the embodiments of the present application, rather than all the embodiments.

[0033] The components of the embodiments of the present application generally described and illustrated in the drawings herein may be arranged and designed in a variety of different configurations. Therefore, the following detailed description of the embodiments of the present application provided in the drawings is not intended to limit the scope of the claimed application, but rather merely represents selected embodiments of the present application. All other embodiments obtained by those skilled in the art based on the embodiments of the present application without creative effort are within the scope of protection of the present application.

[0034] Hereinafter, the terms "including", "having" and their cognates used in various embodiments of the present application are intended only to indicate specific features, numbers, steps, operations, elements, components or combinations of the aforementioned items, and should not be understood as excluding the existence of one or more other features, numbers, steps, operations, elements, components or combinations of the aforementioned items or adding the possibility of one or more features, numbers, steps, operations, elements, components or combinations of the aforementioned items. In addition, the terms "first", "second", "third" and the like are only used to distinguish descriptions and should not be understood as indicating or implying relative importance.

[0035] Unless otherwise defined, all terms used herein (including technical and scientific terms) have the same meaning as commonly understood by those skilled in the art to which the various embodiments of the present application belong. The terms (such as those defined in generally used dictionaries) will be interpreted as having the same meaning as in the context of the relevant technical field and will not be interpreted as having an idealized meaning or an overly formal meaning unless clearly defined in the various embodiments of the present application.

[0036] Below, some embodiments of the present application are described in detail with reference to the accompanying drawings. In the absence of conflict, the following embodiments and the features in the embodiments can be combined with each other. The order release mode of the existing remote diagnostic system mainly adopts two mechanisms: intelligent mode and manual mode. Among them, the intelligent mode implements diagnostic operations through an automated configuration mechanism. The system can automatically detect key parameters such as voltage and baud rate, and generate an intelligent configuration file based on this to complete the configuration of the lower computer, and then carry out diagnostic work. However, this mode has significant limitations at the technical level: when applied to models with more complex system architectures (such as Cadillac, Buick Regal, BYD Tang, etc.), the system will collect a large amount of vehicle data, and the data flow rate usually exceeds 200k / s. This data collection mechanism causes a large amount of non-essential information to be transmitted to the B-end, which not only takes up valuable network bandwidth resources, but also affects the data transmission efficiency of key diagnostic modules, and may eventually lead to the occurrence of diagnostic anomalies such as system scan failure.

[0037] The main drawbacks of the manual profile selection mode are as follows:

[0038] 1. High operational complexity: Manually selecting a configuration file requires users to possess professional automotive diagnostic knowledge, including an accurate understanding of the differences between different brands, models, years, and functional modules. For novice users or non-professional technicians, this professional requirement may lead to operational difficulties or even incorrect selections. In addition, given the wide variety of models in the automotive industry (such as the Audi A6L and BYD Tang), each model may correspond to multiple years and functional modules. Users need to sift through a vast number of configuration options one by one, which not only increases operational complexity but also significantly increases time costs.

[0039] 2. High risk of error: If the user selects the wrong configuration file (e.g., the wrong brand, model, or year), the diagnosis may not proceed properly and may even damage the vehicle system. For example, selecting the "2022 Audi A8L" configuration file for the "2023 Audi A6L" may cause the air conditioning module programming to fail. Furthermore, when manually selecting a configuration file, the user may overlook certain key information (such as the specific version of a functional module), causing the diagnostic data to be inconsistent with the actual vehicle and affecting diagnostic accuracy.

[0040] 3. Low operational efficiency: Users need to spend a lot of time browsing and screening appropriate configuration files, especially when facing complex vehicle models or multi-module diagnosis. This time delay will directly affect the efficiency of the entire remote diagnosis process and reduce the overall performance of the system.

[0041] In summary, both order release modes of the existing remote diagnosis system have significant technical limitations and operational defects, and there is an urgent need to improve diagnostic efficiency and accuracy through technical optimization and system improvement.

[0042] Based on this, the present application proposes a vehicle remote diagnosis method, system, server and storage medium to enable the user to correctly initiate a remote diagnosis request without having professional knowledge of vehicle diagnosis.

[0043] The vehicle remote diagnosis system will be first described below with reference to some specific embodiments.

[0044] Figure 1 FIG2 is a schematic diagram showing a structure of a vehicle remote diagnosis system according to an embodiment of the present application. Schematically, the vehicle remote diagnosis system includes: a client 100 , a web server 200 , and a large model server 300 .

[0045] The web server 200 is used to send the received target order request to the large model server 300.

[0046] The large model server 300 is used to receive a target order request and enable the pre-trained remote diagnosis model to output diagnosis keywords according to the target order request.

[0047] Among them, the remote diagnosis model is obtained by training a large model based on multiple training data; each training data includes a training order request and a corresponding output result.

[0048] The large model server 300 is also used to send the target diagnosis keyword to the web server 200.

[0049] The web server 200 is further configured to determine a corresponding target configuration file path based on the target diagnosis keyword, and send the target configuration file path and the diagnosis keyword to the client 100, so that the client 100 generates a remote diagnosis request based on the target configuration file path and the target diagnosis keyword.

[0050] Exemplarily, the client 100 serves as the entry point for user interaction, is responsible for receiving the user's target order request, and encapsulates the target order request into the prompt_parmeter parameter. The target order request encapsulated into the prompt_parmeter parameter is then sent to the web server via an HTTP request. For example, the user enters a target order request on the client 100 (such as "What should I do if the air conditioner of the 2023 Audi A6L is broken?"), the client 100 encapsulates the target order request entered by the user into the parameter prompt_parameter, and transmits the target order request encapsulated into the prompt_parmeter parameter to the web server 200 via the HTTP protocol.

[0051] The web server 200 serves as the business logic center of the entire system, and is used to receive the target order issuance request encapsulated as the prompt_parmeter parameter sent by the client 100, and access the large model server 300 on AutoDL through the internal tunnel that has been opened, that is, to send the target order issuance request encapsulated as the prompt_parmeter parameter to the large model server 300 through the internal channel.

[0052] It should be noted that after receiving the target order request encapsulated as the prompt_parmeter parameter, the web server 200 will verify the content of the target order request. The verification items include, but are not limited to, checking whether the request format is correct, ensuring the request source is legitimate (such as through API key or token verification), etc., and filtering out target order requests that obviously do not meet the requirements (such as empty input or illegal characters). This verification process ensures that the target order requests received by the large model server 300 are credible.

[0053] The large model server 300 runs on AutoDL (a high-performance server platform). The large model server 300 has a pre-trained remote diagnosis model built in. After the large model server 300 receives the target order request, since the target order request is usually a request in the form of natural language, the target order request is input into the pre-trained remote diagnosis model for processing, and the target diagnosis keyword is inferred and extracted. For example, the target order request is "What should I do if the air conditioner of the 2023 Audi A6L is broken?" After processing, the target diagnosis keywords obtained may include Audi (brand), A6L (model), 2023 (year), and programmable air conditioning module (function). After obtaining the target keyword through the pre-trained remote diagnosis model, the large model server 300 sends the target diagnosis keyword to the web server 200. After receiving the target diagnosis keyword, the web server determines the corresponding target configuration file path through the mapping relationship path between the target diagnosis keyword and the configuration file path.

[0054] It can be understood that the configuration file mapping module of the web server 200 maintains a mapping table of diagnostic keywords and configuration file paths. After obtaining the target diagnostic keyword, the configuration file mapping module determines the matching configuration file path based on the diagnostic keyword output by the large model. In this embodiment, the web server 200 does not directly obtain the target configuration file, but obtains the target configuration file path. This is because the configuration file may contain some sensitive information (such as proprietary algorithms, communication protocol details, etc.). If the configuration file is directly saved on the web server 200, it may cause the leakage of the configuration file. Therefore, in order to ensure the security of the configuration file data, the configuration file is stored locally; on the other hand, since the configuration file is generally large, especially when it involves complex vehicle models or functional modules, it may contain a large number of parameters and instructions. If the Web server sends the target configuration file to the client 100 every time, it will occupy a lot of network bandwidth, especially in high-concurrency scenarios, which may cause network congestion. In this embodiment, only the path of the configuration file is returned, which can significantly reduce the overhead of network transmission.

[0055] Furthermore, after the web server 200 receives the target configuration file path and the target diagnostic keyword, the target configuration file path and the target diagnostic keyword are sent to the client 100. After the client 100 receives the target diagnostic keyword and the corresponding target configuration file path, the client 100 reads the corresponding target configuration file from the local storage according to the target configuration file path. For example, the path points to a JSON file, and the file content may contain specific diagnostic parameters, communication protocols, etc. The client 100 then parses the contents of the configuration file and extracts specific diagnostic instructions (such as module address, baud rate, diagnostic commands, etc.) that match the target diagnostic keyword. The client 100 then combines the target diagnostic keyword and the parsed configuration file content to generate a complete remote diagnostic request, which may include: the target diagnostic keyword and the parameters and instructions required for diagnosis. Finally, the client 100 sends the generated remote diagnostic request to the remote diagnostic system via the network.

[0056] It can be understood that in this embodiment, the remote diagnosis request is not generated directly through the web server 200, but is generated through the client 100. On the one hand, since the client 100 is the direct interface for the user to interact with the system, after the user submits the target order request, he usually wants to get feedback immediately to confirm that the system has received the target order request and generated an order. If the Web server directly forwards the order to the remote diagnosis system without returning any information to the client 100, the user may be confused and do not know whether the request is successfully processed; on the other hand, the information sent by the Web server contains important information, such as: order number, configuration file path, diagnostic keywords (brand, model, year, function), etc. This information is very important to the user and can be used to track the order status or subsequent reference. If it is forwarded directly to the remote diagnosis system, the user may not be able to obtain this information in time.

[0057] In some embodiments, as Figure 2 As shown in Figure 1, the training process of the remote diagnosis model includes:

[0058] In step S210, the order issuance request of each training data is expanded to form order issuance requests in multiple contexts corresponding to each training order issuance request, and the order issuance request in each context and the corresponding output result are used as a set of training data.

[0059] In step S220 , each set of training data is input into the large model for training until the error between the output diagnosis keyword and the corresponding output result reaches a preset cutoff condition, thereby obtaining a remote diagnosis model.

[0060] Before training based on the large model to obtain a remote diagnosis model, you need to create a training environment first. For example, you can rent a high-performance server at the AutoDL server rental center. The configuration parameters of the server include: operating system (Ubuntu 22.04), CUDA version (11.8), graphics driver version (550.78), graphics card type (NVIDIA 4090), PyTorch version (2.1.2) and Python version (3.10). When installing the environment, use Jupyter Notebook to open the server, then install the LLaMA-Factory toolkit, create a Conda virtual environment, and finally download and run the large model (base model GLM-4-9B-Chat). It can be understood that the creation of the environment used for model training is only exemplary. The specific training environment can be set as needed and is not limited here.

[0061] After the training environment is created, you can prepare training data. Each training data consists of two parts: a training request and the corresponding output result. The training data can be stored in the format of a JSON array. Each record includes at least two fields: an instruction field (used to store the request) and an output field (used to store the corresponding output result). The request is a vehicle fault problem described in natural language; the output result includes the brand, model, year, and function. For example, the request can be "Hello, I want to program the air conditioner for the 2022 Audi A6L", and the corresponding output result is "Audi, A6L, 2022, programming air conditioning module".

[0062] Among them, the order requests used for training include vehicle failure questions asked by users in the past and vehicle failure questions formed by random combinations based on brand, model, year and function.

[0063] Because large models require a large amount of high-quality data for training, especially in specific areas (such as remote vehicle diagnosis), relevant real user questions may be very limited. Relying solely on historical question data from real users may result in insufficient data, which in turn affects model performance. Therefore, the training request requests in this embodiment include not only real user questions about vehicle failures, but also randomly combined vehicle failure questions based on brand, model, year, and function.

[0064] For vehicle failure questions generated by random combinations of brand, model, year, and function: The configuration file library contains fixed keywords for various vehicles, including brand, model, year, and function. By randomly combining the brands, models, years, and functions in the configuration file library, a more diverse range of vehicle failure questions can be simulated. This allows the large model to be exposed to a wider range of input types, allowing it to better understand and handle complex or rare questions in real-world applications. Furthermore, while real user data typically requires manual labeling, this random combination approach can automatically generate a large amount of labeled data (for example, "Hello, I want to program the transformation assistance system for the 2022 Audi A6L" can be directly mapped to "Audi, A6L, 2022, Programming transformation assistance system"). This method can significantly reduce data labeling costs and time. Furthermore, by randomly combining information such as year and function, a variety of question formats were generated, such as "2022 Audi A6L programming transformation assistance system" and "2023 Audi A6L air conditioning programming." This generated data covers different vehicle models, years, and function requirements, allowing the large model to more comprehensively learn the various types of questions that users may ask.

[0065] After obtaining enough training order requests and corresponding output results, in this embodiment, the training order requests for each training data need to be expanded to form order requests in multiple contexts corresponding to each training order request, and the order requests in each context and the corresponding output results are used as a set of training data.

[0066] It's understandable that during actual vehicle remote diagnosis, users' actual target order requests are often diverse, potentially including different expressions, tones, and contextual information. For example, "I want to program the air conditioning for my 2022 Audi A6L" could be rewritten as "How do I program the air conditioning for my 2022 Audi A6L?", "Help me solve my Audi A6L air conditioning problem," or "My car is a 2022 Audi A6L, what should I do if I need to program the air conditioning?" In this embodiment, a large model is used to generate multiple question contexts for each order request, simulating these diverse expressions and making the training data more realistic.

[0067] After obtaining the training data, the large model began training. During training, the fine-tuning method selected was LORA (Low-Rank Adaptation), a highly efficient parameter-efficient fine-tuning method. LORA improves performance by adjusting only a small number of model parameters (typically low-rank matrices in fully connected layers), reducing computing resource consumption. Next, set up the fine-tuning environment. First, use the SSH command to establish a tunnel between the local machine and the AutoDL server, allowing direct access to the fine-tuning interface. In the fine-tuning interface, select the base model GLM-4-9B-Chat, load the training dataset, and initiate the fine-tuning process. During the fine-tuning process, the model learns how to map user input (e.g., "How do I program the air conditioning in the 2022 Audi A6L?") to corresponding output results (diagnostic keywords, such as "Audi, A6L, 2022, program air conditioning module"). Through repeated iterative optimization, the model gradually improves its understanding of vehicle remote diagnostic requirements. When the error between the output diagnostic keyword and the corresponding output reaches a preset cutoff, the remote diagnosis model is obtained.

[0068] In some embodiments, the web server 200 includes a first interface; the large model server 300 includes a second interface; the web server 200 receives the target order request through the first interface, and forwards the target order request to the second interface of the large model server 300 through an internal tunnel; the large model server 300 receives the target order request through the second interface, and after the remote diagnosis model outputs the target diagnosis keyword, sends the target diagnosis keyword to the web server 200 through the second interface.

[0069] It can be understood that the first interface can be publish_order, which is responsible for receiving the target order issuance request sent by the client 100 and extracting the prompt_parameter parameter (the natural language description entered by the user). The second interface can be get_prompt, which is an interface on the large model server 300, responsible for receiving the request forwarded from the Web server and calling the fine-tuned large model for reasoning. The client 100 encapsulates the user's target order issuance request as the prompt_parameter parameter and sends it to the publish_order interface of the Web server through an HTTP request. The publish_order interface forwards the request to the get_prompt interface of the large model server 300 through an internal tunnel. The get_prompt interface calls the large model for reasoning and returns the output result.

[0070] In this embodiment, the large model server 300 (such as the Flask service on AutoDL) is usually deployed in the internal network and does not directly provide services to the outside world. By using the Web server as an intermediate layer, the large model server 300 can be isolated from the external environment, reducing the risk of direct exposure. Imagine that if the large model server 300 directly provides services to the outside world, it may be subject to the following attacks: a large number of invalid requests may cause the server to overload, attackers may try to obtain sensitive data or model parameters, etc. In this embodiment, through the indirect request scheme, the Web server can perform preliminary verification and filtering of the target order request, prevent illegal requests from reaching the large model server 300, and thus enhance the security of the system. In addition, this design not only improves the system's anti-attack capability, but also reduces the pressure on the large model server 300, thereby improving overall performance and diagnostic efficiency.

[0071] Figure 3 A flow chart of a vehicle remote diagnosis method according to an embodiment of the present application is shown. Exemplarily, the vehicle remote diagnosis method includes:

[0072] Step S310 , in response to the target order issuance request, transmit the target order issuance request to the pre-trained remote diagnosis model, so that the remote diagnosis model outputs the target diagnosis keyword according to the target order issuance request.

[0073] Among them, the remote diagnosis model is obtained by training a large model based on multiple training data; each training data includes a training order request and a corresponding output result.

[0074] Step S320 : determining a corresponding target configuration file path based on the target diagnosis keyword, and sending the target configuration file path and the target diagnosis keyword to the client 100 , so that the client 100 generates a remote diagnosis request based on the target configuration file path and the target diagnosis keyword.

[0075] It can be understood that the method of this embodiment corresponds to the vehicle remote diagnostic device of the above embodiment, and the options in the above embodiment are also applicable to this embodiment, so they will not be described again here.

[0076] This application solves the problems of manual selection of configuration files in the existing technology during vehicle remote diagnosis, such as easy errors, inability to select, or a large amount of invalid data in the intelligent mode, by introducing a pre-trained remote diagnosis model (a fine-tuned GLM-4-9B-Chat large model). The solution of this application is mainly reflected in the following aspects: First, in terms of demand identification, the pre-trained remote diagnosis model can accurately parse the target order request entered by the user (usually a natural language instruction), and accurately extract key information such as brand, model, year and function through deep learning of the user's question context and vehicle configuration data. Compared with the traditional voltage / baud rate detection method, the amount of invalid data generated can be reduced to near zero, significantly improving the diagnostic accuracy and system scanning capability. Second, in terms of user experience, the client 100 adopts a natural language interaction mode. The user only needs to describe the demand to automatically generate a matching target configuration file, eliminating the operational threshold for manual selection by new and old users, and greatly improving the efficiency of order issuance. Third, the system security uses tunnel technology to isolate the large model server 300, and resists external illegal request attacks through internal interface communication, thereby improving the overall security of the system.

[0077] The present application also provides a server. Exemplarily, the server includes a processor and a memory, wherein the memory stores a computer program, and the processor runs the computer program to enable the terminal device to execute the functions of the various modules in the above-mentioned vehicle remote diagnosis method or the above-mentioned vehicle remote diagnosis device.

[0078] Among them, the processor can be an integrated circuit chip with signal processing capabilities. The processor can be a general-purpose processor, including a central processing unit (CPU), a graphics processing unit (GPU) and a network processor (NP), a digital signal processor (DSP), an application-specific integrated circuit (ASIC), a field programmable gate array (FPGA) or at least one of other programmable logic devices, discrete gate or transistor logic devices, and discrete hardware components. The general-purpose processor can be a microprocessor or the processor can also be any conventional processor, etc., which can implement or execute the disclosed methods, steps and logic block diagrams in the embodiments of the present application.

[0079] The memory may be, but is not limited to, a random access memory (RAM), a read-only memory (ROM), a programmable read-only memory (PROM), an erasable programmable read-only memory (EPROM), an electrically erasable programmable read-only memory (EEPROM), etc. The memory is used to store a computer program, and the processor may execute the computer program accordingly after receiving an execution instruction.

[0080] The present application also provides a computer-readable storage medium for storing the computer program used in the server. For example, the computer-readable storage medium may include, but is not limited to, various media capable of storing program code, such as a USB flash drive, a mobile hard drive, a read-only memory (ROM), a random access memory (RAM), a magnetic disk, or an optical disk.

[0081] In the several embodiments provided in this application, it should be understood that the disclosed devices and methods can also be implemented in other ways. The device embodiments described above are merely schematic. For example, the flowcharts and structure diagrams in the accompanying drawings show the possible architectures, functions and operations of the devices, methods and computer program products according to the multiple embodiments of the present application. In this regard, each box in the flowchart or block diagram can represent a module, a program segment or a part of the code, and the module, program segment or a part of the code contains one or more executable instructions for implementing the specified logical functions. It should also be noted that in an alternative implementation, the functions marked in the box can also occur in an order different from that marked in the accompanying drawings. For example, two consecutive boxes can actually be executed substantially in parallel, and they can sometimes be executed in the opposite order, depending on the functions involved. It should also be noted that each box in the structure diagram and / or flowchart, and the combination of boxes in the structure diagram and / or flowchart, can be implemented using a dedicated hardware-based system that performs the specified function or action, or can be implemented using a combination of dedicated hardware and computer instructions.

[0082] In addition, the functional modules or units in the various embodiments of the present application can be integrated together to form an independent part, or each module can exist independently, or two or more modules can be integrated to form an independent part.

[0083] If the functions are implemented in the form of software function modules and sold or used as independent products, they can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the present application, or the part that contributes to the prior art, or part of the technical solution, can be embodied in the form of a software product, which is stored in a storage medium and includes several instructions for enabling a computer device (which can be a smart phone, personal computer, server, or network device, etc.) to execute all or part of the steps of the method described in each embodiment of the present application.

[0084] The above is only a specific implementation method of the present application, but the scope of protection of the present application is not limited thereto. Any technician familiar with this technical field can easily think of changes or replacements within the technical scope disclosed in this application, which should be covered by the scope of protection of the present application.

Claims

1. A vehicle remote diagnosis method, characterized in that: include: In response to a target order request, the target order request is transmitted to a pre-trained remote diagnosis model, so that the remote diagnosis model outputs a target diagnosis keyword according to the target order request; wherein the remote diagnosis model is obtained by training a large model based on a plurality of training data; each of the training data includes a training order request and a corresponding output result; A corresponding target configuration file path is determined based on the target diagnosis keyword, and the target configuration file path and the target diagnosis keyword are sent to the client, so that the client generates a remote diagnosis request based on the target configuration file path and the target diagnosis keyword.

2. The vehicle remote diagnosis method according to claim 1, characterized in that: The training order request is a vehicle failure problem described in natural language; The output includes make, model, year, and features.

3. The vehicle remote diagnosis method according to claim 2, characterized in that: The training ticket issuance request includes vehicle failure questions asked by users in the past and vehicle failure questions formed by random combinations based on the brand, the model, the year and the function.

4. The vehicle remote diagnosis method according to claim 2, characterized in that: Training the large model based on the plurality of training data to obtain the remote diagnosis model includes: Expanding the training order issuance request of each training data to form order issuance requests in multiple contexts corresponding to each training order issuance request, and using the order issuance request in each context and the corresponding output result as a set of training data; Each set of training data is input into the large model for training until the error between the output diagnostic keyword and the corresponding output result reaches a preset cutoff condition, thereby obtaining the remote diagnostic model; wherein the diagnostic keywords include brand, model, year and function.

5. The vehicle remote diagnosis method according to claim 1, characterized in that: The determining the corresponding target configuration file path based on the target diagnosis keyword includes: The target configuration file path is determined according to the target diagnosis keyword in combination with a mapping relationship between the diagnosis keyword and the configuration file path.

6. A vehicle remote diagnosis system, characterized in that: Client and web server and large model server; The web server is used to send the received target order request to the large model server; The large model server is configured to receive the target order request and enable the pre-trained remote diagnosis model to output a diagnosis keyword based on the target order request; wherein the remote diagnosis model is obtained by training the large model based on a plurality of training data; each of the training data includes a training order request and a corresponding output result; The large model server is further configured to send the target diagnosis keyword to the web server; The web server is further configured to determine a corresponding target configuration file path based on the target diagnosis keyword, and send the target configuration file path and the diagnosis keyword to the client, so that the client generates a remote diagnosis request based on the target configuration file path and the target diagnosis keyword.

7. The vehicle remote diagnosis system according to claim 6, characterized in that: The client is further configured to initiate the target order issuance request, and encapsulate the target order issuance request and transmit it to the web server.

8. The vehicle remote diagnosis system according to claim 6, characterized in that: The web server includes a first interface; the large model server includes a second interface; The web server receives the target order request through the first interface, and forwards the target order request to the second interface of the large model server through an internal tunnel; The large model server receives the target order request through the second interface, and after the remote diagnosis model outputs the target diagnosis keyword, sends the target diagnosis keyword to the web server through the second interface.

9. A server, characterized in that: The server includes a processor and a memory, wherein the memory stores a computer program, and the processor is configured to execute the computer program to implement the vehicle remote diagnosis method according to any one of claims 1 to 6.

10. A computer-readable storage medium, characterized in that The device stores a computer program, which, when executed on a processor, implements the vehicle remote diagnosis method according to any one of claims 1 to 6.

Images