Remote diagnostic method and system

Abstract

Embodiments of the present application relate to the field of vehicle diagnostics, and disclosed are a remote diagnostic system and method. The remote diagnostic system comprises a first communication device and a server. Once the first communication device obtains the VIN code of a vehicle, the VIN code is sent to the server. The server looks up communication attribute data corresponding to the VIN code in a pre-stored communication attribute database according to the VIN code, assembles and generates a target configuration file, and sends the target configuration file to the first communication device; the first communication device receives the target configuration file, establishes a communication link and filters ECU messages from the vehicle according to the target configuration file, and sends ECU messages that remain after filtering to the server, so as to enable the server to forward the remaining ECU messages to a second communication device, and then be received by a diagnostic device to perform diagnostic work. By this means, remote diagnostics can be implemented, and a broader range of vehicle fault resolution measures is provided. The present method can also provide service to many vehicle lines, and thus possesses general applicability.

Description

Remote diagnosis method and system

[0001] This application claims priority to the Chinese patent application filed with the China Patent Office on November 28, 2023, with application number 202311614554.6 and application name “Remote Diagnosis Method and System”, the entire contents of which are incorporated by reference into this application. Technical Field

[0002] The embodiments of the present application relate to the field of automobile diagnosis technology, and in particular to a remote diagnosis system and method. Background Art

[0003] With the development of society and the advancement of science and technology, electronic control units (ECUs) are increasingly being incorporated into the design and production of automobiles. This, while contributing to a higher degree of automation, superior performance, and more convenient and flexible operation, also places higher demands on vehicle maintenance. Traditional manual maintenance methods are no longer sufficient. Consequently, auto repair shops both domestically and internationally are now equipped with diagnostic equipment to detect faults in vehicle-related systems.

[0004] However, diagnostic equipment is typically provided by the original vehicle manufacturer and can only identify bus messages specific to a specific vehicle series or model. This means it only works with that specific vehicle series or model and is not universally applicable. Repair shops need to purchase different diagnostic equipment for different vehicle series, which is expensive and resource-intensive. Furthermore, there may be faults that repair personnel cannot resolve, requiring the assistance of specialized technical experts. Consequently, offline diagnosis is inefficient. Summary of the Invention

[0005] The main technical problem solved by the embodiments of the present application is to provide a remote diagnosis method and system that can achieve accurate and effective remote diagnosis and provide a wider range of automobile fault resolution methods; it can also serve a variety of car series and has universality; in addition, it can also integrate expert resources and diagnostic equipment resources.

[0006] In a first aspect, some embodiments of the present application provide a remote diagnostic method, applied to a first communication device, the first communication device being used to communicate with a car and a server, and the second communication device being used to communicate with the server and a diagnostic device; the method comprising:

[0007] Obtain the vehicle identification number (VIN) of the car and send it to the server, so that the server can search the communication attribute data corresponding to the VIN in a pre-stored communication attribute database based on the VIN and assemble and generate a target configuration file. The target configuration file reflects the electronic control unit (ECU) identification and communication attributes of the car series.

[0008] Receive the target configuration file, establish a communication link and filter the ECU message from the car according to the target configuration file, and send the filtered ECU message to the server, so that the server forwards the filtered ECU message to the second communication device, which is then received by the diagnostic device for diagnosis.

[0009] In some embodiments, the target configuration file includes a number of ECU identifiers, and the ECU identifiers correspond to communication parameters;

[0010] The aforementioned steps, based on the target configuration file, establish a communication link and filter messages from the vehicle's ECU, include:

[0011] Establish a communication link of the bus to which the ECU belongs according to the communication parameters identified by the ECU;

[0012] Edit several ECU identifiers to form multiple filters. The filters are used to allow ECU messages to pass when the ECU identifier of any ECU message falls within the ECU identifier range covered by the filter.

[0013] Multiple filters are used to filter the ECU messages from the car, and the filtered ECU messages are sent to the server.

[0014] In some embodiments, the multiple filters include multiple precise filters and multiple fuzzy filters, the precise filters cover one ECU identifier, and the fuzzy filters cover at least two ECU identifiers.

[0015] In some embodiments, the aforementioned method of filtering ECU messages from the vehicle using multiple filters and sending the filtered ECU messages to the server includes:

[0016] The ECU messages from the car are first filtered using multiple precise filters. If they do not match, they are then filtered using multiple fuzzy filters. The ECU messages that pass the secondary filtering are then sent to the server.

[0017] In a second aspect, some embodiments of the present application provide a remote diagnosis method, applied to a server, where the server is configured to communicate with a first communication device and a second communication device, where the first communication device is configured to connect to a vehicle, and the second communication device is configured to connect to a diagnostic device. The method includes:

[0018] Receiving the vehicle identification number (VIN) of the car sent by the first communication device;

[0019] According to the VIN code, the communication attribute data corresponding to the VIN code is searched in a pre-stored communication attribute database, and a target configuration file is generated by assembling the target configuration file. The target configuration file reflects the electronic control unit ECU identification and communication attributes of the car series;

[0020] Sending the target configuration file to the first communication device, so that the first communication device establishes a communication link and filters ECU messages from the vehicle according to the target configuration file, and sends the filtered ECU messages to the server;

[0021] The filtered ECU message is forwarded to the second communication device, and then received by the diagnostic device for diagnosis.

[0022] In some embodiments, the communication attribute database includes a correspondence between brands and communication attribute data.

[0023] The aforementioned process of searching for communication attribute data corresponding to the VIN code in a pre-stored communication attribute database and assembling and generating a target configuration file includes:

[0024] The car brand is parsed based on the VIN code, the communication attribute data corresponding to the car brand is found in the communication attribute database, and the target configuration file is assembled and generated.

[0025] In a third aspect, an embodiment of the present application provides a first communication device, including:

[0026] at least one processor, and

[0027] a memory communicatively coupled to at least one processor, wherein:

[0028] The memory stores instructions that can be executed by at least one processor, and the instructions are executed by the at least one processor to enable the at least one processor to perform the method of the first aspect.

[0029] In a fourth aspect, some embodiments of the present application provide a server, including:

[0030] at least one processor, and

[0031] a memory communicatively coupled to at least one processor, wherein:

[0032] The memory stores instructions that can be executed by at least one processor, and the instructions are executed by the at least one processor to enable the at least one processor to perform the method of the second aspect.

[0033] In a fifth aspect, some embodiments of the present application provide a remote diagnostic system, comprising the first communication device of the third aspect and the server of the fourth aspect, wherein the first communication device is used to connect the car and the server, and the second communication device is used to connect the server and the diagnostic device.

[0034] In a sixth aspect, some embodiments of the present application provide a computer storage medium, wherein the computer storage medium stores computer-executable instructions, and the computer-executable instructions are used to enable a computer to execute the method of the first aspect or the second aspect.

[0035] Beneficial effects of the embodiments of the present application: Different from the prior art, the remote diagnosis system provided by the embodiments of the present application includes a first communication device and a server, wherein the first communication device is communicatively connected to the car and the server, and the second communication device is communicatively connected to the server and the diagnostic device. After the first communication device obtains the VIN code of the car, it sends the VIN code to the server. Based on the VIN code, the server searches for the communication attribute data corresponding to the VIN code in a pre-stored communication attribute database, assembles and generates a target configuration file, and sends the target configuration file to the first communication device, wherein the target configuration file reflects the ECU identification of the car series to which the car belongs and its communication attributes. After receiving the target configuration file, the first communication device establishes a communication link and filters the ECU message from the car according to the target configuration file, and sends the filtered ECU message to the server, so that the server forwards the filtered ECU message to the second communication device, which is then received by the diagnostic device for diagnosis.

[0036] In this embodiment, the vehicle and diagnostic equipment are connected in communication via a first communication device, a server, and a second communication device, enabling remote diagnosis and providing a wider range of solutions for vehicle faults. Remote diagnosis can integrate expert resources and diagnostic equipment resources to improve maintenance efficiency. Furthermore, the server pre-stores a communication attribute database covering communication attribute data for a variety of different vehicle series, enabling the provision of target configuration files for the current vehicle, enabling the diagnostic system to serve a variety of vehicle series and provide universal functionality. Furthermore, the first communication device filters ECU messages from the vehicle, ensuring that the filtered ECU messages are recognizable by the diagnostic equipment. Transmitting the filtered ECU messages to the diagnostic equipment via the server and the second communication device effectively reduces interference data during remote diagnosis and improves diagnostic efficiency and accuracy. BRIEF DESCRIPTION OF THE DRAWINGS

[0037] One or more embodiments are exemplarily illustrated by pictures in the corresponding drawings. These exemplifications do not constitute limitations on the embodiments. Elements with the same reference numerals in the drawings are represented as similar elements. Unless otherwise stated, the figures in the drawings do not constitute proportional limitations.

[0038] FIG1 is a schematic diagram of the structure of a remote diagnosis system in some embodiments of the present application;

[0039] FIG2 is a schematic diagram of the structure of a remote diagnosis system in some other embodiments of the present application;

[0040] FIG3 is a flowchart of a remote diagnosis method applied to a first communication device in some embodiments of the present application;

[0041] FIG4 is a schematic diagram showing the connections between various ECUs and buses in an automobile control system according to some embodiments of the present application;

[0042] FIG5 is a flow chart of a remote diagnosis method applied to a server in some embodiments of the present application;

[0043] FIG6 is an interactive diagram of a remote diagnosis method in some embodiments of the present application;

[0044] FIG7 is a schematic structural diagram of a first communication device in some embodiments of the present application;

[0045] FIG8 is a schematic diagram of the structure of a server in some embodiments of the present application. DETAILED DESCRIPTION

[0046] The present application is described in detail below with reference to specific embodiments. The following embodiments will help those skilled in the art to further understand the present application, but are not intended to limit the present application in any form. It should be noted that those skilled in the art may make several variations and improvements without departing from the scope of the present application. These all fall within the scope of protection of the present application.

[0047] In order to make the purpose, technical solutions and advantages of this application more clear, the following further describes this application in detail with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are only used to explain this application and are not intended to limit this application.

[0048] It should be noted that, if there is no conflict, the various features in the embodiments of the present application can be combined with each other and are all within the scope of protection of the present application. In addition, although the functional modules are divided in the device schematic and the logical order is shown in the flow chart, in some cases, the steps shown or described can be performed in a different order than the module division in the device or the order in the flow chart. In addition, the words "first", "second", "third", etc. used herein do not limit the data and execution order, but only distinguish between the same items or similar items with basically the same functions and effects.

[0049] Unless otherwise defined, all technical and scientific terms used in this specification have the same meanings as those commonly understood by those skilled in the art to which this application belongs. The terms used in this specification and in the specification of this application are only for the purpose of describing specific embodiments and are not intended to limit this application. The term "and / or" as used in this specification includes any and all combinations of one or more of the relevant listed items.

[0050] In addition, the technical features involved in each embodiment of the present application described below can be combined with each other as long as they do not conflict with each other.

[0051] Please refer to Figure 1, which is a structural diagram of a remote diagnostic system 100 provided in some embodiments of the present application. The remote diagnostic system 100 includes a first communication device 10, a second communication device 20 and a server 30. The first communication device 10 is communicatively connected to the car 50 and the server 30, and the second communication device 20 is communicatively connected to the server 30 and the diagnostic device 40.

[0052] The first communication device 10 can be a vehicle communication interface (VCI), i.e., an electronic device with computing and processing capabilities that integrates a communication interface, such as an OBD interface. The first communication device 10 can communicate with the OBD interface of the vehicle 50 via the OBD interface. The first communication device 10 can convert data on the vehicle bus into data recognizable by the server 30, and can also convert data sent by the server 30 into data recognizable by the vehicle bus. In addition, the first communication device 10 also has wireless communication capabilities and can communicate with the server 30 via a network such as WIFI, or can communicate with the server 30 via a wired connection, making communication more reliable. In some embodiments, the first communication device 10 also includes a touch screen display, so that it can receive operator operations or display operating instructions, diagnostic conditions, or related data.

[0053] Referring to FIG. 2 , in some embodiments, the first communication device 10 includes a first communication apparatus 11 and a first mobile terminal 12, which are independent of each other. Here, the first communication apparatus 11 may be a VCI, and the first mobile terminal 12 may be a tablet computer, a smart phone, or various forms of handheld smart devices. In this embodiment, the first communication apparatus 11 is connected to the OBD interface of the automobile 50 by wire, and is also connected to the first mobile terminal 12 by wire, such as by a USB wired connection. The first mobile terminal 12 is connected to the server 30 via a network such as WIFI. The first mobile terminal 12 may also be connected to the server 30 by a wired connection to make communication more reliable. It is understood that the first mobile terminal 12 includes a touch screen display, so that it can receive the operator's operations or display operation instructions, diagnostic conditions, or related data.

[0054] The second communication device 20 can be a VCI, i.e., an electronic device with computing processing capabilities, which has an integrated communication interface, such as an OBD interface. The second communication device 20 can communicate with the OBD interface of the diagnostic device 40 via the OBD interface. The second communication device 20 can convert data on the diagnostic device bus into data recognizable by the server 30, and can also convert data sent by the server 30 into data recognizable by the diagnostic device 40 bus. In addition, the second communication device 20 can have wireless communication capabilities and can communicate with the server 30 via a network such as Wi-Fi, or via a wired connection, making communication more reliable. In some embodiments, the second communication device 20 also includes a touch screen display, thereby being able to receive operator operations or display operating instructions, diagnostic conditions, or related data.

[0055] Referring again to Figure 2, in some embodiments, the second communication device 20 includes a second communication apparatus 21 and a second mobile terminal 22, which are independent of each other. Here, the second communication apparatus 21 may be a VCI, and the second mobile terminal 22 may be a tablet computer, a smartphone, or various forms of handheld smart devices. The second communication apparatus 21 and the second mobile terminal 22 are connected to each other via an IoT server 31, which is specifically responsible for transmitting commands for synchronizing the human-computer interaction state.

[0056] In this embodiment, the second communication device 21 is connected to the OBD interface of the diagnostic device 40 via a wired connection and is also connected to the second mobile terminal 22 via a server network. The second mobile terminal 22 is connected to the server 30 via a network cable or Wi-Fi. It will be appreciated that the second mobile terminal 22 includes a touchscreen display, which can receive operator commands and display operating instructions, diagnostic results, or related data.

[0057] That is, the first communication device 10 and the second communication device 20 can be identical, having the same hardware and software. The only difference is that the first communication device 10 is used on the near-vehicle side, communicating between the OBD interface of the vehicle 50 and the server 30, while the second communication device 20 is used on the far-vehicle side, communicating between the diagnostic device 40 and the server 30. Those skilled in the art will appreciate that the terms "first" and "second" do not limit the communication devices in any way.

[0058] The server 30 can be a local physical server or a cloud device, such as a cloud server, cloud host, cloud service platform, or cloud computing platform. The cloud device is connected to the first communication device 10 or the second communication device 20 via a network, and the two devices communicate with each other via a predetermined communication protocol. Specifically, the communication protocol can be TCP / IP or other protocols. In other embodiments, the first communication device 10 and the second communication device 20 can communicate with each other using a P2P protocol. In this way, the first communication device 10 and the second communication device 20 do not need to communicate with each other through the server 30. In other words, the remote diagnosis system 100 may not include the server 30.

[0059] The diagnostic device 40 is a portable intelligent vehicle fault self-test instrument for detecting vehicle faults. The user can use it to quickly read faults in the vehicle's electronic control system and display fault information on a liquid crystal display screen, quickly identifying the location and cause of the fault. It is understandable that the diagnostic device 40 can adopt an existing automotive diagnostic instrument on the market, which includes a host computer 42 and a slave computer 41. The two can be connected by wired or wireless connection, such as via a USB cable, Bluetooth, or WIFI. The host computer 42 can be a tablet, computer, or other device for human-computer interaction, and the slave computer 41 can be a VCI for communication between the host computer 42 and the second communication device 21. The structure and working principle of the diagnostic device 40 are well known to those skilled in the art and will not be described in detail here.

[0060] In some embodiments, the first communication device 10 (e.g., the first mobile terminal therein) and the second communication device 20 (e.g., the second mobile terminal therein) are both loaded with application software. It is understood that the application software serves as a platform for remote communication. A requester near the vehicle can post a help question on the application software on the first communication device 10 or the first mobile terminal and upload it to the server 30. A relevant technical expert can obtain the help question on the application software on the second communication device 20 or the second mobile terminal, thereby helping the requester resolve the help question.

[0061] Through the above-described method, a communication network is formed from the vehicle to the first communication device 10, server 30, second communication device 20, and diagnostic device 40. Within this communication network, any two entities can communicate with each other, allowing the diagnostic device 40 to be unrestricted by geographic location, i.e., not necessarily confined to the vicinity of the vehicle. This allows for remote diagnosis, providing a wider range of troubleshooting options for the vehicle. For example, when maintenance personnel at a car repair shop are unable to resolve a problem, they can seek remote assistance from more experienced technical experts. Through the above-described communication network, the vehicle 50 and diagnostic device 40 can be connected to each other to resolve the problem. For another example, when the repair shop's diagnostic equipment doesn't match the model of the faulty vehicle, remote communication with a matching diagnostic device 30 can be used to resolve the problem. This shows that remote diagnosis can integrate expert resources and diagnostic equipment resources, improving maintenance efficiency.

[0062] The above is merely an example of the remote diagnostic system 100. The remote diagnostic system 100 may also be implemented using other hardware plus software methods. For example, the functions of the second communication device 20 may be implemented using software. A network communication interface may be added to the software of the diagnostic device 40 to transmit data with the server 30 via the network communication interface.

[0063] Some embodiments of the present application provide a remote diagnostic method, which is applied to a first communication device. Referring again to FIG. 1 or FIG. 2 , the first communication device 10 is communicatively connected to a vehicle 50 and a server, and the second communication device 20 is communicatively connected to the server and the diagnostic device 40. The structures of the first communication device 10, the second communication device 20, and the server can be found in the description of the aforementioned remote diagnostic system embodiment.

[0064] Referring to FIG. 3 , the remote diagnosis method A100 applied to the first communication device includes but is not limited to the following steps:

[0065] A10: The vehicle identification number (VIN) of the vehicle is obtained and sent to the server. The server searches for communication attribute data corresponding to the VIN in a pre-stored communication attribute database based on the VIN and assembles the target configuration file. The target configuration file reflects the ECU identification and communication attributes of the vehicle series.

[0066] As you can understand, the VIN code stands for Vehicle Identification Number (VIN), which contains information such as the vehicle's manufacturer (brand), year of production, model, body type, engine code, and assembly location. The VIN code generally consists of three parts: the manufacturer identification code (WMI), the vehicle description section (VDS), and the vehicle indicator section (VIS).

[0067] In some embodiments, when the first communication device is connected to the vehicle's OBD interface, its processor can automatically retrieve the VIN code from the vehicle's bus, eliminating the need for additional operation and enabling intelligent retrieval. In some embodiments, an operator can also input the vehicle's VIN code through an input terminal (e.g., a touchscreen display) of the first communication device, thereby allowing the processor of the first communication device to retrieve the VIN code.

[0068] After the processor of the first communication device obtains the VIN code, it sends it to the server. Based on the VIN code, the server searches a pre-stored communication attribute database for communication attribute data corresponding to the VIN code, assembles and generates a target configuration file, and sends the target configuration file to the first communication device. The target configuration file reflects the ECU identification and communication attributes of the vehicle's model.

[0069] The communication attribute database includes the ECU identifications and communication attributes of different vehicle series, for example, the identifications and communication attributes of each ECU in a Great Wall vehicle.

[0070] Refer to Figure 4. The automotive control system consists of multiple buses and multiple electronic control units (ECUs). Each bus is connected to at least one ECU, and buses that require connectivity are connected via gateways, making the automotive control system a complex control network. Buses can be configured with different communication protocols, including CAN, K-Line, PWM / VPWM, FlexRay, SAE J1708, and LIN. ECUs control the vehicle's driving state. Common ECUs include the engine management system (EMS), transmission control unit (TCU), and body control module (BCM). A gateway is a device that connects two buses and can be a router or switch. During actual operation, each ECU sends a signal to its corresponding bus. The signal is transmitted on or across the bus, enabling communication between ECUs.

[0071] It is understandable that each ECU in the control system of a car has its own identity. Here, the ECU identifier in the communication attribute database is the identity document (ID) of the ECU in the corresponding car series. Each ECU in the control system of a car is connected to the bus and can communicate using the above-mentioned multiple communication protocols. Here, the communication attributes of the ECU reflect the communication protocol to which the ECU belongs. In some embodiments, the communication attributes of the ECU can be represented by communication parameters. In some embodiments, the communication parameters include ECU pins, baud rates or protocol identifiers, etc. In some embodiments, if the communication protocol is the DOIP protocol, the communication parameters include pins, protocols or modes. Among them, the mode is an automatic detection mode or a determination mode.

[0072] In some embodiments, the communication attribute database stored in the server includes a correspondence between brands and communication attribute data. In this embodiment, the server parses the vehicle's brand based on the VIN code, then searches the communication attribute data corresponding to the vehicle's brand in the communication attribute database and assembles the data to generate a target configuration file. The server then sends the target configuration file to the first communication device, which then receives the target configuration file. The specific method for searching and assembling the target configuration file can be found in the description of step B20 in the following method embodiment and will not be repeated here.

[0073] A20: Receive the target configuration file, establish a communication link and filter the ECU messages from the vehicle according to the target configuration file, and send the filtered ECU messages to the server, so that the server forwards the filtered ECU messages to the second communication device, which is then received by the diagnostic device for diagnosis.

[0074] It is understood that the target configuration file includes several ECU identifiers, each of which corresponds to communication parameters, such as ECU pins, baud rate, or protocol identifiers. The ECUs corresponding to these ECU identifiers are distributed on different buses, and different buses can use different communication protocols, such as CAN, K-Line, PWM / VPWM, FlexRay, SAE J1708, LIN, and other protocols.

[0075] Those skilled in the art will appreciate that, in addition to physical lines, a communication link also requires a communication protocol to control data transmission. Hardware and software that implement these protocols combined with physical lines constitute a communication link.

[0076] It can be seen that after the first communication device is connected to the OBD interface of the car to form a physical line, a communication protocol needs to be established to form a communication link. In other words, establishing a communication link of the bus to which the ECU belongs is equivalent to establishing a communication protocol in the communication link.

[0077] After the communication link is established, the first communication device filters the ECU message from the car and sends the filtered ECU message to the server.

[0078] It is understandable that after the diagnostic device sends a request message to the vehicle bus through the remote communication network, each ECU in the vehicle sends an ECU message based on the request message. Thus, the first communication device can receive the ECU message from the vehicle. The diagnostic data output by the vehicle bus includes ECU messages sent by each ECU in the vehicle and a large number of interference messages. The first communication device filters the ECU messages from the vehicle and sends the filtered ECU messages to the server, which is then sent to the second communication device through the server and then received by the diagnosed device for diagnosis. In this way, the interference messages in remote diagnosis can be effectively reduced, so that the diagnostic device receives matching and recognizable ECU messages, thereby improving the efficiency and accuracy of diagnosis. In addition, the first communication device only needs to parse the filtered ECU messages. The data volume is relatively small, which also reduces the data parsing pressure of the first communication device, can reduce the hardware configuration requirements for the first communication device, and reduce costs.

[0079] In some embodiments, the aforementioned “establishing a communication link and filtering ECU messages from the vehicle according to the target configuration file” includes:

[0080] A21: Establish a communication link of the bus to which the ECU belongs based on the communication parameters identified by the ECU.

[0081] It is understandable that, for these several ECUs, some of them correspond to the same bus, that is, the corresponding communication protocols are the same. Here, for each ECU, the bus to which it belongs and the corresponding communication protocol are first determined. In some embodiments, the processor of the first communication device determines the communication protocol to which it belongs based on the ECU pin, baud rate or protocol identifier in the communication parameters of the ECU identifier. Then, the corresponding controller is controlled to establish the communication protocol, thereby completing the establishment of the communication link. It is understandable that controllers with different protocols are provided in the first communication device, such as a CAN controller. These controllers with different protocols are existing in the art and are well known to those skilled in the art, and will not be introduced in detail here.

[0082] For example, if the communication protocol of a certain ECU identifier is the CAN protocol, the ECU pin, protocol identifier, and baud rate in the communication parameters are input into the CAN controller, and the CAN controller establishes the CAN protocol. The CAN protocol and the bus corresponding to the ECU identifier form a communication link.

[0083] A22: Edit several ECU IDs to form multiple filters. The filter is used to allow ECU messages to pass if the ECU ID of any ECU message falls within the ECU ID range covered by the filter.

[0084] It can be understood that a filter is a program module that encapsulates one or more ECU identifiers, that is, it covers one or more ECU identifiers. The filter compares ECU messages from the vehicle with the ECU identifiers it covers. If the ECU identifier of a message from the vehicle falls within the ECU identifier range covered by the filter, the ECU message is allowed to pass. If the ECU identifier of a message from the vehicle does not fall within the ECU identifier range covered by the filter, the ECU message is not allowed to pass. Thus, the filter implements the filtering function of ECU messages.

[0085] In some embodiments, the multiple filters include multiple precise filters and multiple fuzzy filters, the precise filters cover one ECU identifier, and the fuzzy filters cover at least two ECU identifiers.

[0086] In this embodiment, several ECU identifiers in the target configuration file are compiled to form multiple precise filters and multiple fuzzy filters. It is understandable that if each ECU identifier constitutes a filter, there would be too many filters, which would occupy a large amount of memory. To conserve memory on the first communication device, some ECU identifiers are individually used to form precise filters, each covering only one ECU identifier. Similar ECU identifiers are then combined to form fuzzy filters, each covering at least two ECU identifiers.

[0087] For example, the similar ECU identifiers (i.e., ECUIDs) of 711, 712, 713, 714, 715, 716, 717, and 718 are merged into "20000710." The last digit 0 in "20000710" represents the 16 numbers 0-F (i.e., the 16 numbers 0-15), and the first digit 2 represents that this is a merged fuzzy filter.

[0088] In this embodiment, by merging a portion of ECUs into a fuzzy filter and allowing multiple precise filters and multiple fuzzy filters to coexist, the memory pressure of the first communication device can be effectively reduced.

[0089] In some embodiments, the precise filters in the first communication device may be stored in ascending order of ECUID, while the fuzzy filters do not impose any restrictions on the order.

[0090] A23: Use multiple filters to filter the ECU messages from the car, and send the filtered ECU messages to the server.

[0091] When the first communication device receives an ECU message, the processor compares the message's ECU ID with the filter. If a match is found, the message is allowed to pass. The filtered message is then sent to the server, which then forwards it to the second communication device and the diagnostic device, ensuring that the diagnostic device receives clean, valid ECU messages.

[0092] In some embodiments, the aforementioned step A23 specifically includes: first filtering the ECU message from the car using multiple precise filters, and if it does not match, then filtering it using multiple fuzzy filters, and sending the ECU message that passes the secondary filtering to the server.

[0093] When the first communication device receives an ECU message, the processor compares the message's ECU identifier (ECUID) with the precise filter using a binary search method. If a match is found (the ECUID of the ECU message matches the ECUID of the precise filter), the message is allowed to pass. If no precise filter matches, the ECUID of the ECU message is compared against the fuzzy filter one by one. If the ECUID of the ECU message falls within the range of ECUIDs covered by a fuzzy filter, the match is successful and the message is allowed to pass. The ECU message that passes the secondary filtering is then sent to the server, which then distributes it to the second communication device and the diagnostic device, ensuring that the diagnostic device receives clean and valid ECU messages.

[0094] In this embodiment, by first using a binary search method to filter in multiple precise filters and then using multiple fuzzy filters to filter, the filtering time can be effectively reduced and the transmission efficiency of the remote channel can be improved.

[0095] In summary, the remote diagnostic method provided in some embodiments of the present application is applied to a first communication device that is communicatively connected between a vehicle and a server, and a second communication device that is communicatively connected between the server and a diagnostic device. This method obtains the vehicle's VIN code and sends it to a server, so that the server searches a pre-stored communication attribute database for communication attribute data corresponding to the VIN code based on the VIN code and assembles a target configuration file. The target configuration file reflects the ECU identification and communication attributes of the vehicle series to which the vehicle belongs. The target configuration file is received, and based on the target configuration file, a communication link is established and ECU messages from the vehicle are filtered. The filtered ECU messages are then sent to the server, so that the server forwards the filtered ECU messages to the second communication device, which is then received by the diagnostic device for diagnostic work.

[0096] This approach enables remote diagnosis, providing a wider range of vehicle troubleshooting solutions. Remote diagnosis can integrate expert resources and diagnostic equipment resources, improving repair efficiency. Furthermore, the first communication device filters ECU messages from the vehicle, ensuring that only those messages that pass the filter are recognizable by the diagnostic device. These filtered ECU messages are then sent to the diagnostic device via the server and the second communication device, effectively reducing interference data during remote diagnosis and improving diagnostic efficiency and accuracy.

[0097] It is understood that the second communication device has the same structure and function as the first communication device, except that the second communication device is used for the diagnostic device end, communicating with the server and the diagnostic device. In this remote diagnostic service, the second communication device is used to forward messages.

[0098] Some embodiments of the present application provide a remote diagnostic method, which is applied to a server. Referring again to FIG. 1 or FIG. 2 , a first communication device 10 is communicatively connected between a vehicle 50 and a server 30, and a second communication device 20 is communicatively connected between the server 30 and a diagnostic device 40. The remote diagnostic method may be executed by one or more processors of the server 30.

[0099] Referring to FIG. 5 , the remote diagnosis method B100 applied to the server includes but is not limited to the following steps:

[0100] B10: Receive the vehicle identification number (VIN) of the car sent by the first communication device.

[0101] As you can understand, the VIN code stands for Vehicle Identification Number (VIN), which contains information such as the vehicle's manufacturer (brand), year of production, model, body type, engine code, and assembly location. The VIN code generally consists of three parts: the manufacturer identification code (WMI), the vehicle description section (VDS), and the vehicle indicator section (VIS).

[0102] In some embodiments, when the first communication device is connected to the vehicle's OBD interface, its processor can automatically retrieve the VIN code from the vehicle's bus, eliminating the need for additional operation and enabling intelligent retrieval. In some embodiments, an operator can also input the vehicle's VIN code through an input terminal (e.g., a touchscreen display) of the first communication device, thereby allowing the processor of the first communication device to retrieve the VIN code.

[0103] After the processor of the first communication device obtains the VIN code, it sends the VIN code to the server, thereby enabling the server to receive the vehicle identification number (VIN) code of the car sent by the first communication device.

[0104] B20: Based on the VIN code, the communication attribute data corresponding to the VIN code is searched in a pre-stored communication attribute database and assembled to generate a target configuration file. The target configuration file reflects the electronic control unit (ECU) identification and communication attributes of the vehicle series.

[0105] The communication attribute database includes the ECU identifications and communication attributes of different vehicle series, for example, the identifications and communication attributes of each ECU in a Great Wall vehicle.

[0106] It is understandable that each ECU in the control system of a car has its own identity. Here, the ECU identifier in the communication attribute database is the identity document (ID) of the ECU in the corresponding car series. Each ECU in the control system of a car is connected to the bus and can communicate using the above-mentioned multiple communication protocols. Here, the communication attributes of the ECU reflect the communication protocol to which the ECU belongs. In some embodiments, the communication attributes of the ECU can be represented by communication parameters. In some embodiments, the communication parameters include ECU pins, baud rates or protocol identifiers, etc. In some embodiments, if the communication protocol is the DOIP protocol, the communication parameters include pins, protocols or modes. Among them, the mode is an automatic detection mode or a determination mode.

[0107] In some embodiments, the communication attribute database includes a correspondence between brands and communication attribute data. The aforementioned step B20 specifically includes: parsing the brand of the car based on the VIN code, searching the communication attribute data corresponding to the brand of the car in the communication attribute database, and assembling and generating a target configuration file.

[0108] In some embodiments, the VIN code can also be parsed by a third-party server using an existing parsing model, and the parsed brand, year of production, and model number can be sent to the server in the diagnostic system. Specifically, after the first communication device obtains the VIN code, it sends the VIN code to third-party server 1 for relay to another third-party server 2. Third-party server 2 uses an existing parsing model to parse the VIN code to determine the manufacturer (brand), year of production, and model number of the vehicle, and then sends the parsed information to the server in the diagnostic system.

[0109] In some embodiments, the operator can also directly input the manufacturer (brand), production year, and model of the car through the input end of the first communication device, and the first communication device will forward the manufacturer (brand), production year, and model to the server in the diagnostic system through the third-party server 1.

[0110] In this embodiment, the server receives the brand, production year and model of the car, and then searches the communication attribute database for communication attribute data corresponding to the brand of the car, and assembles and generates a target configuration file.

[0111] Based on the above embodiment, the communication attribute database includes the ECU identification of the vehicle series and its communication attributes (i.e., communication parameters, including ECU pins, baud rates or protocol identifications, etc.), in some embodiments, the target configuration file includes several ECU identifications, and each ECU identification corresponds to a communication parameter, i.e., ECU pins, baud rates or protocol identifications, etc.

[0112] In this embodiment, by setting the communication attribute database to include the correspondence between the brand and the communication attribute data, searching by brand is not restricted by the production year of the car, compared to searching by VIN code, and can effectively reduce the situation of search mismatches, which is beneficial to the smooth progress of diagnosis.

[0113] In some embodiments, if the number of communication attribute data corresponding to the car brand found exceeds a preset number (e.g., 200), some of the communication attribute data are combined to generate a target configuration file of 200. For example, similar ECU identifiers of the same link can be combined.

[0114] In some embodiments, the server stores multiple masks. The server is further configured to compare the VIN code with these masks. If the VIN code matches a mask, the vehicle is determined to be a special vehicle, a corresponding special node is generated, and the special node is sent to the first communication device. When the first communication device receives the special node, it generates a corresponding near-end compensation frame to facilitate communication. If the VIN code does not match any of the masks, the vehicle is determined to be a regular vehicle, a regular node is generated, and the regular node is sent to the first communication device.

[0115] B30: Send the target configuration file to the first communication device, so that the first communication device establishes a communication link and filters ECU messages from the car according to the target configuration file, and sends the filtered ECU messages to the server.

[0116] The specific implementation manner in which the first communication device establishes a communication link and filters ECU messages from the vehicle according to the target configuration file can be referred to the description of step A20 in the above embodiment and will not be repeated here.

[0117] B40: Forward the filtered ECU message to the second communication device, which is then received by the diagnostic device for diagnosis.

[0118] After receiving the filtered ECU messages, the server sends these ECU messages to the second communication device, which is then received by the diagnostic device for diagnosis.

[0119] This approach enables the server to pre-store a database of communication attributes covering a wide range of vehicle models. This allows for targeted configuration files to be provided for the specific vehicle, making the diagnostic system universally applicable across multiple vehicle models. Furthermore, this effectively reduces interference messages during remote diagnosis, ensuring that the diagnostic equipment receives matching, recognizable ECU messages, improving diagnostic efficiency and accuracy.

[0120] In some embodiments, referring to FIG. 6 , the first communication device and the server use the following interactive process to complete remote diagnosis.

[0121] S101: The diagnostic device sends request information to the vehicle bus via the second communication device, the server, and the first communication device in sequence.

[0122] S102: Each ECU in the car sends an ECU message to the first communication device based on the request information.

[0123] S103: The first communication device obtains the VIN code of the car.

[0124] As you can understand, the VIN code stands for Vehicle Identification Number (VIN), which contains information such as the vehicle's manufacturer (brand), year of production, model, body type, engine code, and assembly location. The VIN code generally consists of three parts: the manufacturer identification code (WMI), the vehicle description section (VDS), and the vehicle indicator section (VIS).

[0125] In some embodiments, when the first communication device is connected to the vehicle's OBD interface, the first communication device automatically retrieves the VIN code from the vehicle's bus, eliminating the need for additional operation. In some embodiments, an operator can also input the vehicle's VIN code through an input terminal (e.g., a touchscreen display) of the first communication device, thereby allowing the first communication device to retrieve the VIN code.

[0126] S104: After obtaining the VIN code, the first communication device sends the VIN code to the server.

[0127] S105: The server searches for communication attribute data corresponding to the VIN code in a pre-stored communication attribute database based on the VIN code, and assembles the data into a target configuration file, wherein the target configuration file reflects the ECU identification and communication attributes of the car series.

[0128] S106: The server sends the target configuration file to the first communication device.

[0129] The communication attribute database includes the ECU identifications and communication attributes of different vehicle series, for example, the identifications and communication attributes of each ECU in a Great Wall vehicle.

[0130] It is understandable that each ECU in the control system of a car has its own identity. Here, the ECU identifier in the communication attribute database is the identity document (ID) of the ECU in the corresponding car series. Each ECU in the control system of a car is connected to the bus and can communicate using the above-mentioned multiple communication protocols. Here, the communication attributes of the ECU reflect the communication protocol to which the ECU belongs. In some embodiments, the communication attributes of the ECU can be represented by communication parameters. In some embodiments, the communication parameters include ECU pins, baud rates or protocol identifiers, etc. In some embodiments, if the communication protocol is the DOIP protocol, the communication parameters include pins, protocols or modes. Among them, the mode is an automatic detection mode or a determination mode.

[0131] In some embodiments, a communication attribute database stored in a server includes a correspondence between brands and communication attribute data. In this embodiment, the server parses the car's brand based on the VIN code, then searches the communication attribute database for the corresponding communication attribute data for the car's brand and assembles the target configuration file.

[0132] In some embodiments, the VIN code can also be parsed by a third-party server using an existing parsing model, and the parsed brand, year of production, and model number can be sent to the server in the diagnostic system. Specifically, after the first communication device obtains the VIN code, it sends the VIN code to third-party server 1 for relay to another third-party server 2. Third-party server 2 uses an existing parsing model to parse the VIN code to determine the manufacturer (brand), year of production, and model number of the vehicle, and then sends the parsed information to the server in the diagnostic system.

[0133] In some embodiments, the operator can also directly input the manufacturer (brand), production year, and model of the car through the input end of the first communication device, and the first communication device will forward the manufacturer (brand), production year, and model to the server in the diagnostic system through the third-party server 1.

[0134] In this embodiment, the server receives the brand, production year and model of the car, and then searches the communication attribute database for communication attribute data corresponding to the brand of the car, and assembles and generates a target configuration file.

[0135] In this embodiment, by setting the communication attribute database to include the correspondence between the brand and the communication attribute data, searching by brand is not restricted by the production year of the car, compared to searching by VIN code, and can effectively reduce the situation of search mismatches, which is beneficial to the smooth progress of diagnosis.

[0136] In some embodiments, if the number of communication attribute data corresponding to the car brand found exceeds a preset number (e.g., 200), some of the communication attribute data are combined to generate a target configuration file of 200. For example, similar ECU identifiers of the same link can be combined.

[0137] In some embodiments, the server stores multiple masks. The server is further configured to compare the VIN code with these masks. If the VIN code matches a mask, the vehicle is determined to be a special vehicle, a corresponding special node is generated, and the special node is sent to the first communication device. When the first communication device receives the special node, it generates a corresponding near-end compensation frame to facilitate communication. If the VIN code does not match any of the masks, the vehicle is determined to be a regular vehicle, a regular node is generated, and the regular node is sent to the first communication device.

[0138] S107: After receiving the target configuration file, the first communication device establishes a communication link and filters ECU messages from the vehicle according to the target configuration file.

[0139] S108: The first communication device sends the filtered ECU message to the server.

[0140] S109: The server forwards the filtered ECU message to the second communication device.

[0141] S110: The second communication device forwards the filtered ECU message to the diagnostic device.

[0142] S111: The diagnostic device performs diagnostic work.

[0143] It is understood that when the diagnostic device sends a request message to the vehicle bus via the remote communication network, each ECU in the vehicle sends an ECU message to the first communication device based on the request message. Thus, the first communication device can receive the ECU message from the vehicle.

[0144] Based on the above embodiment, the communication attribute database includes the ECU identification of the vehicle series and its communication attributes (i.e., communication parameters, including ECU pins, baud rates or protocol identifications, etc.), in some embodiments, the target configuration file includes several ECU identifications, and each ECU identification corresponds to a communication parameter, i.e., ECU pins, baud rates or protocol identifications, etc.

[0145] In this embodiment, the first communication device establishes a communication link of the bus to which the ECU identifier belongs according to the communication parameters of the ECU identifier.

[0146] It's understood that a vehicle control system includes multiple buses, each of which hosts at least one ECU. These buses can utilize different communication protocols, such as CAN, K-Line, PWM / VPWM, FlexRay, SAE J1708, and LIN. It's understood that each bus corresponds to a specific communication protocol.

[0147] Those skilled in the art will appreciate that, in addition to physical lines, a communication link also requires a communication protocol to control data transmission. Hardware and software that implement these protocols combined with physical lines constitute a communication link.

[0148] It can be seen that after the first communication device is connected to the OBD interface of the car to form a physical line, a communication protocol needs to be established to form a communication link. In other words, establishing a communication link of the bus to which the ECU belongs is equivalent to establishing a communication protocol in the communication link.

[0149] It is understandable that, for these several ECUs, some of them correspond to the same bus, that is, the corresponding communication protocols are the same. Here, for each ECU, the bus to which it belongs and the corresponding communication protocol are first determined. In some embodiments, the first communication device determines the communication protocol to which it belongs based on the ECU pin, baud rate or protocol identifier in the communication parameters of the ECU identifier. Then, the corresponding controller is used to establish the communication protocol, thereby completing the establishment of the communication link. It is understandable that controllers with different protocols are provided in the first communication device, such as a CAN controller. These controllers with different protocols are existing in the art and are well known to those skilled in the art, and will not be introduced in detail here.

[0150] For example, if the communication protocol of an ECU is the CAN protocol, the ECU pin, protocol identifier, and baud rate in the communication parameters are input into the CAN controller, which then establishes the CAN protocol. The CAN protocol forms a communication link with the bus corresponding to the ECU.

[0151] After establishing a communication link, the first communication device filters the ECU messages from the car and sends the filtered ECU messages to the server. It is understandable that the diagnostic data output by the car bus includes ECU messages sent by each ECU in the car and a large number of interference messages. The first communication device filters the ECU messages from the car and sends the filtered ECU messages to the server and diagnostic device. This can effectively reduce the interference messages in remote diagnosis, allowing the diagnostic device to receive matching and recognizable ECU messages, thereby improving the efficiency and accuracy of diagnosis. In addition, the first communication device only needs to parse the filtered ECU messages, and the data volume is relatively small, which also reduces the data parsing pressure of the first communication device, can reduce the hardware configuration requirements for the first communication device, and reduce costs.

[0152] The first communication device edits a plurality of ECU identifiers to form a plurality of filters. The filters are used to allow an ECU message to pass when the ECU identifier of any ECU message falls within the range of ECU identifiers covered by the filters.

[0153] It can be understood that a filter is a program module that encapsulates one or more ECU identifiers, that is, it covers one or more ECU identifiers. The filter compares ECU messages from the vehicle with the ECU identifiers it covers. If the ECU identifier of a message from the vehicle falls within the ECU identifier range covered by the filter, the ECU message is allowed to pass. If the ECU identifier of a message from the vehicle does not fall within the ECU identifier range covered by the filter, the ECU message is not allowed to pass. Thus, the filter implements the filtering function of ECU messages.

[0154] In some embodiments, the plurality of filters include a plurality of precise filters and a plurality of fuzzy filters, wherein the precise filters cover one ECU identifier and the fuzzy filters cover at least two ECU identifiers.

[0155] In this embodiment, several ECU identifiers in the target configuration file are compiled to form multiple precise filters and multiple fuzzy filters. It is understandable that if each ECU identifier constitutes a filter, there would be too many filters, which would occupy a large amount of memory. To conserve memory on the first communication device, some ECU identifiers are individually used to form precise filters, each covering only one ECU identifier. Similar ECU identifiers are then combined to form fuzzy filters, each covering at least two ECU identifiers.

[0156] For example, the similar ECU identifiers (i.e., ECUIDs) of 711, 712, 713, 714, 715, 716, 717, and 718 are merged into "20000710." The last digit 0 in "20000710" represents the 16 numbers 0-F (i.e., the 16 numbers 0-15), and the first digit 2 represents that this is a merged fuzzy filter.

[0157] In this embodiment, by merging a portion of ECUs into a fuzzy filter and allowing multiple precise filters and multiple fuzzy filters to coexist, the memory pressure of the first communication device can be effectively reduced.

[0158] In some embodiments, the precise filters in the first communication device may be stored in ascending order of ECUID, while the fuzzy filters do not impose any restrictions on the order.

[0159] In some embodiments, the first communication device first filters the ECU message from the car using multiple precise filters. If it does not match, it then filters it using multiple fuzzy filters and sends the ECU message that passes the secondary filtering to the server.

[0160] When the first communication device receives an ECU message, it compares the message's ECU ID with the precise filter using a binary search method. If a match is found (the message's ECU ID matches the precise filter's ECU ID), the message is allowed to pass. If no precise filter matches, the message's ECU ID is then compared against the fuzzy filter. If the ECU ID falls within the range of ECU IDs covered by a fuzzy filter, the match is successful and the message is allowed to pass. The ECU message, which passes the secondary filter, is then sent to the server, which then distributes it to the second communication device and the diagnostic device, ensuring that the diagnostic device receives clean, valid ECU messages.

[0161] In this embodiment, by first using a binary search method to filter in multiple precise filters and then using multiple fuzzy filters to filter, the filtering time can be effectively reduced and the transmission efficiency of the remote channel can be improved.

[0162] In some embodiments, please refer to FIG. 2 again. The first communication device 10 includes a first communication apparatus 11 and a first mobile terminal 12 that are communicatively connected. The first communication apparatus 11 is used to connect to the car 50 , and the first mobile terminal 12 is used to communicate with the server.

[0163] The first communication device 11 may be a vehicle communication interface (i.e., a VCI device). The first mobile terminal 12 may be a tablet computer, a smartphone, or various forms of handheld smart devices. In this embodiment, the first communication device 11 is connected to the OBD interface of the vehicle 50 via a wired connection and to the first mobile terminal 12 via a USB interface. The first mobile terminal 12 is connected to the server via a network cable or Wi-Fi.

[0164] The first mobile terminal 12 receives and parses the target configuration file and sends the parsed link establishment instruction to the first communication device 11. The first communication device 11 then establishes a communication link based on the parsed link establishment instruction and filters ECU messages from the vehicle. The filtered ECU messages are then sent to the first mobile terminal 12, which forwards the filtered ECU messages to the server, which then forwards them to the diagnostic device 40 via the second communication device 20 for diagnostic work.

[0165] In this embodiment, the first mobile terminal is loaded with application software. It is understood that the application software serves as a remote communication platform. A requester near the vehicle can post a help request on the application software on the first mobile terminal and upload it to the server. It is also understood that the first mobile terminal also includes a built-in program module for parsing the target configuration file, which can utilize existing parsing algorithms corresponding to the program module.

[0166] When a remote technical expert is found and remote diagnosis is started, the first mobile terminal receives the target configuration file sent by the server and forwards the link establishment instruction generated by the analysis to the first communication device. It can be understood that the first mobile terminal can not only transmit data but also provide an interactive interface to facilitate remote assistance.

[0167] The first communication device is provided with controllers of various communication protocols, such as a CAN controller, etc., for establishing a communication link. For the specific establishment process, please refer to the above description and will not be repeated here.

[0168] The filtering control program module is stored in the first communication device. For example, it contains a program module for editing and generating filters and corresponding filter functions. Thus, ECU messages from the vehicle are filtered and sent to the first mobile terminal for upload to the server. The server then sends the messages to the remote second communication device.

[0169] To summarize, after obtaining the car's VIN code, the first communication device sends it to a server. Based on the VIN code, the server searches a pre-stored communication attribute database for the corresponding communication attribute data, assembles a target configuration file, and sends it to the first communication device. The target configuration file reflects the ECU identifier and communication attributes of the car's model. After receiving the target configuration file, the first communication device establishes a communication link and filters ECU messages from the car based on the target configuration file (after the diagnostic device sends a request to the car bus via a remote communication network, each ECU in the car sends an ECU message to the first communication device based on the request). The server then forwards the filtered ECU messages to the second communication device, which then receives them for diagnostic purposes.

[0170] In this embodiment, the automobile and the diagnostic device are connected in communication through the first communication device, the server, and the second communication device, thereby enabling remote diagnosis and providing a wider range of solutions to automobile faults. Remote diagnosis can integrate expert resources and diagnostic equipment resources to improve maintenance efficiency. In addition, the communication attribute database pre-stored in the server covers communication attribute data for a variety of different car series, thereby being able to provide target configuration files for the current car, enabling the diagnostic system to serve a variety of car series and be universal. In addition, the first communication device filters the ECU messages from the car so that the filtered ECU messages can be recognized by the diagnostic device. Sending the filtered ECU messages to the diagnostic device through the server and the second communication device can effectively reduce interference data in remote diagnosis and improve the efficiency and accuracy of diagnosis.

[0171] Some embodiments of the present application also provide a first communication device, please refer to Figure 7, the first communication device 10 includes at least one processor 11 and a memory 12 connected via a bus (Figure 7 shows an example of a processor and a memory connected to the bus).

[0172] The processor 11 is used to provide computing and control capabilities to control the first communication device 10 to execute any one of the remote diagnosis methods applied to the first communication device provided in the above embodiments.

[0173] It is understandable that the processor 11 can be a general-purpose processor, including a central processing unit (CPU), a network processor (NP), etc.; it can also be a digital signal processor (DSP), an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA) or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components.

[0174] The memory 12, as a non-transitory computer-readable storage medium, can be used to store non-transitory software programs, non-transitory computer executable programs, and modules, such as program instructions / modules corresponding to the remote diagnostic method applied to the first communication device 10 in the embodiments of the present application. The processor 11 can implement any of the remote diagnostic methods applied to the first communication device provided in the above embodiments by running the non-transitory software programs, instructions, and modules stored in the memory 12.

[0175] Some embodiments of the present application further provide a server, see FIG8 , the server 30 includes at least one processor 31 and a memory 32 connected via a bus ( FIG8 exemplarily illustrates one processor and one memory connected to the bus).

[0176] The processor 31 is used to provide computing and control capabilities to control the server 30 to execute any one of the remote diagnosis methods applied to the server provided in the above embodiments.

[0177] It is understandable that the processor 31 can be a general-purpose processor, including a central processing unit (CPU), a network processor (NP), etc.; it can also be a digital signal processor (DSP), an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA) or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components.

[0178] Memory 32, as a non-transitory computer-readable storage medium, can be used to store non-transitory software programs, non-transitory computer-executable programs, and modules, such as the program instructions / modules corresponding to the remote diagnostic methods applied to the server in the embodiments of the present application. Processor 31 can implement any of the remote diagnostic methods applied to the server provided in the aforementioned embodiments by executing the non-transitory software programs, instructions, and modules stored in memory 32.

[0179] It is understandable that the server 30 can be a local physical server or a cloud device, such as a cloud server, a cloud host, a cloud service platform, a cloud computing platform, etc., and no limitation is imposed on the server method.

[0180] Some embodiments of the present application also provide a remote diagnostic system including the first communication device and the server in the above embodiments, wherein the first communication device is used to connect the car and the server, and the second communication device is used to connect the server and the diagnostic device.

[0181] It will be appreciated that the first communication device in this remote diagnostic system has the same structure and functions as the first communication device in the aforementioned embodiment. The server has the same structure and functions as the server in the aforementioned embodiment. Thus, the remote diagnostic system can implement the interactive method described in Figure 6 , meaning that the remote diagnostic system can integrate expert resources and diagnostic equipment resources to improve maintenance efficiency. Furthermore, the server pre-stores a communication attribute database covering communication attribute data for a variety of different vehicle series, enabling the provision of target profiles tailored to the current vehicle, enabling the diagnostic system to serve a wide range of vehicle series and providing universal functionality. Furthermore, the first communication device filters ECU messages from the vehicle, ensuring that only those messages that pass the filter are recognizable by the diagnostic device. Transmitting these filtered ECU messages to the diagnostic device via the server and the second communication device effectively reduces interference data during remote diagnosis and improves diagnostic efficiency and accuracy.

[0182] Some embodiments of the present application further provide a computer storage medium storing computer executable instructions, which are used to enable a computer to execute the remote diagnosis method applied to the first communication device or the remote diagnosis method applied to the server in any one of the above method embodiments.

[0183] It should be noted that the device embodiments described above are merely illustrative, wherein the units described as separate components may or may not be physically separate, and the components shown as units may or may not be physical units, that is, they may be located in one place or distributed across multiple network units. Some or all of the modules may be selected based on actual needs to achieve the objectives of this embodiment.

[0184] Through the description of the above embodiments, those skilled in the art can clearly understand that each embodiment can be implemented by means of software plus a general hardware platform, or of course by hardware. Those skilled in the art can understand that all or part of the processes in the above embodiment methods can be implemented by instructing the relevant hardware through a computer program, and the program can be stored in a computer-readable storage medium. When the program is executed, it can include the processes of the embodiments of the above methods. Among them, the storage medium can be a magnetic disk, an optical disk, a read-only memory (ROM) or a random access memory (RAM), etc.

[0185] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present application, rather than to limit them. Based on the concept of the present application, the technical features in the above embodiments or different embodiments can also be combined, the steps can be implemented in any order, and there are many other variations in different aspects of the present application as described above. For the sake of simplicity, they are not provided in detail. Although the present application has been described in detail with reference to the aforementioned embodiments, those skilled in the art should understand that they can still modify the technical solutions described in the aforementioned embodiments, or make equivalent replacements for some of the technical features therein. These modifications or replacements do not deviate the essence of the corresponding technical solutions from the scope of the technical solutions of the embodiments of the present application.

Claims

1. A remote diagnosis method, applied to a first communication device, characterized in that: The first communication device is used to communicate with the car and the server, and the second communication device is used to communicate with the server and the diagnostic device; the method includes: Obtaining the vehicle identification number (VIN) of the automobile and sending it to the server, so that the server searches for communication attribute data corresponding to the VIN in a pre-stored communication attribute database according to the VIN, and assembles and generates a target configuration file, wherein the target configuration file reflects the electronic control unit (ECU) identifier and communication attribute of the vehicle series to which the automobile belongs; The target configuration file is received, a communication link is established and ECU messages from the vehicle are filtered according to the target configuration file, and the filtered ECU messages are sent to the server, so that the server forwards the filtered ECU messages to the second communication device, which is then received by the diagnostic device for diagnosis.

2. The remote diagnosis method according to claim 1, characterized in that: The target configuration file includes a plurality of ECU identifiers, and the ECU identifiers correspond to communication parameters; The step of establishing a communication link and filtering ECU messages from the vehicle according to the target configuration file includes: Establishing a communication link of the bus to which the ECU belongs according to the communication parameters identified by the ECU; The plurality of ECU identifiers are edited to form a plurality of filters, wherein the filters are used to allow the ECU message to pass when the ECU identifier of any ECU message falls within the range of ECU identifiers covered by the filters; The multiple filters are used to filter the ECU messages from the automobile, and the filtered ECU messages are sent to the server.

3. The remote diagnosis method according to claim 2, characterized in that: The multiple filters include multiple precise filters and multiple fuzzy filters, the precise filters cover one ECU identifier, and the fuzzy filters cover at least two ECU identifiers.

4. The remote diagnosis method according to claim 3, characterized in that: The using the multiple filters to filter the ECU messages from the automobile, and sending the filtered ECU messages to the server, comprises: The ECU message from the car is first filtered by the multiple precise filters. If it does not match, it is then filtered by the multiple fuzzy filters. The ECU message after the secondary filtering is sent to the server.

5. A remote diagnosis method, applied to a server, characterized in that: The server is used to communicate with a first communication device and a second communication device, the first communication device is used to connect to a car, and the second communication device is used to connect to a diagnostic device; the method includes: Receiving the vehicle identification number (VIN) code of the automobile sent by the first communication device; According to the VIN code, communication attribute data corresponding to the VIN code is searched in a pre-stored communication attribute database, and a target configuration file is assembled to generate the target configuration file, wherein the target configuration file reflects the electronic control unit ECU identification and communication attribute of the vehicle series to which the vehicle belongs; Sending the target configuration file to the first communication device, so that the first communication device establishes a communication link and filters ECU messages from the vehicle according to the target configuration file, and sends the filtered ECU messages to the server; The filtered ECU message is forwarded to the second communication device, and then received by the diagnostic device for diagnosis.

6. The remote diagnosis method according to claim 5, characterized in that: The communication attribute database includes the corresponding relationship between brands and communication attribute data, The method of searching for communication attribute data corresponding to the VIN code in a pre-stored communication attribute database according to the VIN code and assembling and generating a target configuration file comprises: The brand of the car is parsed based on the VIN code, the communication attribute data corresponding to the brand of the car is searched in the communication attribute database, and the target configuration file is assembled and generated.

7. A first communication device, characterized in that: include: at least one processor, and a memory communicatively coupled to the at least one processor, wherein: The memory stores instructions that can be executed by the at least one processor, and the instructions are executed by the at least one processor to enable the at least one processor to perform the method according to any one of claims 1 to 4.

8. A server, characterized in that: include: at least one processor, and a memory communicatively coupled to the at least one processor, wherein: The memory stores instructions executable by the at least one processor, and the instructions are executed by the at least one processor to enable the at least one processor to perform the method of claim 5 or 6.

9. A remote diagnosis system, characterized in that: It comprises the first communication device as claimed in claim 7 and the server as claimed in claim 8, wherein the first communication device is used to connect the car and the server, and the second communication device is used to connect the server and the diagnostic device.

10. A computer storage medium, characterized in that: The computer storage medium stores computer executable instructions, and the computer executable instructions are used to enable a computer to execute the method according to any one of claims 1 to 6.

Images