Vehicle diagnosis method and device

Abstract

The invention discloses a vehicle diagnosis method and device and relates to the technical field of vehicles. The method can solve the problem that the software fault, the performance reliability problem and the like of the domain controller in the vehicle are difficult to diagnose by reading fault codes, data streams and the like, and realizes the diagnosis of the domain controller in the vehicle. The method is applied to a vehicle including at least one component including at least one domain controller therein. The method comprises the steps that a first domain controller in at least one domain controller receives a diagnosis instruction from a server, the diagnosis instruction is used for initiating diagnosis of a to-be-diagnosed component, and the to-be-diagnosed component is one or more of at least one component contained in a vehicle. And then the first domain controller obtains to-be-diagnosed data of the to-be-diagnosed part according to the diagnosis instruction, wherein the to-be-diagnosed data is used for diagnosing the to-be-diagnosed part.

Description

Technical Field

[0001] The present application relates to the field of vehicle technology, and in particular to a vehicle diagnosis method and device. Background Art

[0002] With the continuous popularization and development of network technology, remote diagnosis has gradually been applied to vehicle diagnosis, improving the convenience of diagnostic operation and maintenance. Among them, remote diagnosis refers to the method of simulating a diagnostic instrument through a cloud server to perform basic operations such as reading the vehicle's fault code and data stream to diagnose and repair the vehicle. Since the fault code and data stream only carry a small amount of information when the hardware fails, this method can solve the diagnosis of hardware failures in traditional electronic control unit (ECU) components in the vehicle.

[0003] With the continuous development of automotive electronic and electrical architecture, vehicles have evolved from the traditional distributed architecture centered on ECU components to a regional centralized architecture centered on domain controllers. Compared with traditional ECU components, domain controllers are more likely to have software failures such as software failures and performance reliability issues, and these software failures are difficult to diagnose through the above-mentioned methods of reading fault codes and data streams. Summary of the invention

[0004] The present application provides a vehicle diagnosis method and device, which can solve the problems of software failures and performance reliability problems of the domain controller in the vehicle that are difficult to diagnose by reading fault codes, data streams, etc., and realize the diagnosis of the domain controller in the vehicle.

[0005] In order to achieve the above purpose, this application adopts the following technical solutions:

[0006] In a first aspect, a vehicle diagnostic method is provided, which is applied to a vehicle including at least one component, wherein the at least one component includes at least one domain controller, and the method comprises: a first domain controller receives a diagnostic instruction from a server, the first domain controller belongs to the at least one domain controller, the diagnostic instruction is used to initiate a diagnosis of a component to be diagnosed, and the component to be diagnosed is one or more of the at least one component; the first domain controller obtains data to be diagnosed of the component to be diagnosed according to the diagnostic instruction, and the data to be diagnosed is used to diagnose the component to be diagnosed.

[0007] Based on the above technical solution, the domain controller in the vehicle can receive a diagnostic instruction from the server for initiating diagnosis of the component to be diagnosed in the vehicle, and then the domain controller can obtain the data to be diagnosed of the component to be diagnosed according to the diagnostic instruction, and the data to be diagnosed can be used to diagnose the component to be diagnosed. For example, the component to be diagnosed can be a domain controller, etc. In this way, by obtaining the data used to diagnose the domain controller, the diagnosis of the domain controller can be realized. The diagnosis of the domain controller in the vehicle is realized, which can solve the problems of software failures, performance reliability problems of the domain controller in the vehicle, etc., which are difficult to diagnose by reading fault codes, data streams, etc.

[0008] In a possible design, the first domain controller has a diagnostic function, and the diagnostic instruction is used to instruct the first domain controller to initiate diagnosis of the vehicle; the first domain controller obtains the data to be diagnosed of the component to be diagnosed according to the diagnostic instruction, including: the first domain controller receives a diagnostic task from the server according to the diagnostic instruction; the first domain controller obtains the data to be diagnosed according to the diagnostic task. Based on this design, when the first domain controller can diagnose the vehicle, after receiving the diagnostic instruction from the server, the first domain controller determines to initiate diagnosis of the vehicle according to the diagnostic instruction, and then further receives a diagnostic task from the server according to the diagnostic instruction, and determines which data to obtain according to the diagnostic task, and the data can be used to diagnose the domain controller and other components in the vehicle. The diagnosis of the domain controller in the vehicle can be realized, and the problems of software failures, performance reliability problems of the domain controller in the vehicle, etc., which are difficult to diagnose by reading fault codes, data streams, etc. can be solved.

[0009] In a possible design, the diagnostic task carries one or more of the identification of the component to be diagnosed, the indicator item to be diagnosed, the diagnosis type, the identification of the diagnostic process, and the time period in which the data to be diagnosed is located. Based on this design, the diagnostic task carries various information such as the identification of the component to be diagnosed, the indicator item to be diagnosed, the diagnosis type, the identification of the diagnostic process, and the time period in which the data to be diagnosed is located, so that the first domain controller can determine which component to diagnose, which data to be diagnosed, and which diagnostic process to use for diagnosis according to the diagnostic task, and then perform diagnostic operations according to the diagnostic task, so as to realize the diagnosis of software failures, performance reliability problems, etc. of the domain controller in the vehicle.

[0010] In a possible design, after the first domain controller obtains the data to be diagnosed according to the diagnostic task, the method further includes: the first domain controller diagnoses the component to be diagnosed according to the diagnostic task and the data to be diagnosed; and the first domain controller sends the diagnostic result to the server. Based on this design, the domain controller in the vehicle diagnoses the vehicle components (such as the domain controller, etc.) according to the diagnostic task, the data to be diagnosed, etc., so as to diagnose the software faults, performance reliability problems, etc. of the domain controller in the vehicle.

[0011] In one possible design, the diagnosis type corresponds to the diagnosis process represented by the identifier of the diagnosis process. In this way, different diagnosis types (such as user experience fault diagnosis, scenario fault diagnosis, and log fault diagnosis) can correspond to different diagnosis processes, that is, different diagnosis processes can be used to diagnose different types of faults, which can achieve more accurate diagnosis of the cause of the fault.

[0012] In one possible design, the diagnosis type is used to determine whether human-computer interaction is required during the diagnosis of the component to be diagnosed. Based on this design, the first domain controller can determine whether human-computer interaction is required according to the diagnosis type during the diagnosis of the component to be diagnosed. For example: If it is determined that human-computer interaction is required, the first domain controller can interact with the user through the human-computer interaction interface to more accurately determine the cause of the fault. If it is determined that human-computer interaction is not required, the first domain controller may not interact with the user, which can avoid disturbing the user and reduce device power consumption.

[0013] In one possible design, a smart diagnostic application is deployed in the first domain controller, and the smart diagnostic application is used to implement the diagnostic function. Based on this design, by deploying the smart diagnostic application in the domain controller, the diagnostic function of the domain controller can be implemented, so that the domain controller can complete the diagnosis of the components in the vehicle.

[0014] In a possible design, after the first domain controller obtains the data to be diagnosed of the component to be diagnosed according to the diagnostic instruction, the method further includes: the first domain controller sends the data to be diagnosed to the server, and the data to be diagnosed is used by the server to diagnose the component to be diagnosed. Based on this design, the domain controller sends the acquired data to be diagnosed to the server, and the server diagnoses the components in the vehicle based on the data to be diagnosed. In this way, the vehicle side only needs to upload data and does not need to perform diagnostic operations, which can make the development of the vehicle side simpler. In addition, the server computing power is more sufficient, which can make the diagnosis more efficient and the diagnostic effect better.

[0015] In a possible design, the first domain controller is the component to be diagnosed. Based on this design, when the server performs a diagnostic operation, the domain controller to be diagnosed can directly send its own data to be diagnosed to the server, so that the diagnosis of the domain controller can be realized. In this way, the vehicle-side domain controller only needs to perform a data upload operation, which can make the development of the domain controller simpler.

[0016] In a possible design, the diagnostic instruction carries one or more of the identifier of the component to be diagnosed, the indicator item to be diagnosed, and the time period in which the data to be diagnosed is located. Based on this design, when the server performs a diagnostic operation, the server can directly carry the identifier of the component to be diagnosed, the indicator item to be diagnosed, the time period in which the data to be diagnosed is located, etc. through the diagnostic instruction to notify the vehicle end to upload which data of which component, without having to notify the vehicle end by issuing a diagnostic task, which can make development simpler.

[0017] In a possible design, the first domain controller receives the diagnostic instruction from the server, including: the first domain controller receives the diagnostic instruction from the server based on the MQTT protocol. Based on this design, the first domain controller can directly communicate with the server to receive the diagnostic instruction from the server.

[0018] In a possible design, the first domain controller receives a diagnostic instruction from a server, including: a second domain controller receives the diagnostic instruction from the server based on the MQTT protocol, the second domain controller belongs to the at least one domain controller, and the second domain controller is different from the first domain controller; the second domain controller sends the diagnostic instruction to the first domain controller. Based on this design, the first domain controller can also receive the diagnostic instruction of the server through other domain controllers.

[0019] In a possible design, the data to be diagnosed includes at least one type of CAN snapshot, log file, and fault code. In this way, by collecting the data to be diagnosed of the domain controller, such as CAN snapshot, log file, etc., and analyzing these files, the diagnosis of the software failure, performance reliability problem, etc. of the domain controller can be realized. For example: if the domain controller of the vehicle has a problem of slow Internet access, by collecting CAN snapshots and log files containing various information such as the network rate, network format, and chip parameters of the domain controller, it is analyzed that the slow Internet access is caused by parameter settings, and the specific cause of the slow Internet access can be diagnosed.

[0020] In a possible design, the log file includes a dot log, which is used to record information about fault events that occur during the operation of the software system of the component to be diagnosed; the dot log uses a preset encapsulation format. Based on this design, fault events are specifically recorded through the dot log, and the dot log uses a unified format, so that the dot log can be quickly analyzed, and the diagnosis can be completed more efficiently, thereby improving the diagnostic efficiency.

[0021] In a possible design, the preset encapsulation format includes a first field, a second field, a third field, and a fourth field. The first field is used to store the identifier of the component to be diagnosed, the second field is used to store the identifier of the dot log, the third field is used to store the occurrence time of the fault event, and the fourth field is used to store the fault event. In this way, the preset encapsulation format uses a json structure, which can make it easier for operation and maintenance personnel to understand and analyze the data to be diagnosed when diagnosing the vehicle.

[0022] In one possible design, the domain controller includes one or more of: CDC, MDC, VDC, and T-BOX.

[0023] In a second aspect, a vehicle diagnostic method is provided, which is applied to a server, and the method includes: the server generates a diagnostic instruction, and the diagnostic instruction is used to initiate a diagnosis of a component to be diagnosed contained in a vehicle, and the vehicle contains at least one component, and the component to be diagnosed is one or more of the at least one component; the server sends the diagnostic instruction to a first domain controller, and the at least one component contains at least one domain controller, and the first domain controller belongs to the at least one domain controller.

[0024] In one possible design, after the server sends the diagnostic instruction to the first domain controller, the method further includes: the server sends a diagnostic task to the first domain controller according to the diagnostic instruction, the diagnostic task is used to obtain the data to be diagnosed of the component to be diagnosed, and the data to be diagnosed is used to diagnose the component to be diagnosed.

[0025] In a possible design, the diagnostic task carries one or more of the identifier of the component to be diagnosed, the indicator item to be diagnosed, the diagnosis type, the identifier of the diagnostic process, and the time period of the data to be diagnosed.

[0026] In one possible design, after the server sends a diagnostic task to the first domain controller according to the diagnostic instruction, the method further includes: the server receiving a diagnostic result from the first domain controller.

[0027] In one possible design, the diagnosis type corresponds to a diagnosis process represented by an identifier of the diagnosis process.

[0028] In a possible design, the diagnosis type is used to determine whether human-computer interaction is required during the diagnosis of the component to be diagnosed.

[0029] In one possible design, the server has a diagnostic function. After the server sends a diagnostic task to the first domain controller according to the diagnostic instruction, the method further includes: the server receives the data to be diagnosed from the first domain controller; and the server diagnoses the component to be diagnosed according to the data to be diagnosed.

[0030] In one possible design, an intelligent diagnostic application is deployed in the server, and the intelligent diagnostic application is used to implement the diagnostic function.

[0031] In one possible design, the first domain controller is the component to be diagnosed.

[0032] In a possible design, the diagnostic instruction carries one or more of an identifier of the component to be diagnosed, an indicator item to be diagnosed, and a time period in which the data to be diagnosed is located.

[0033] In one possible design, the data to be diagnosed includes at least one type of CAN snapshot, log file, and fault code.

[0034] In a possible design, the log file includes a dot log, and the dot log is used to record information about fault events that occur during the operation of the software system of the component to be diagnosed; the dot log adopts a preset packaging format.

[0035] In one possible design, the preset encapsulation format includes a first field, a second field, a third field and a fourth field. The first field is used to save the identifier of the component to be diagnosed, the second field is used to save the identifier of the dot log, the third field is used to save the occurrence time of the fault event, and the fourth field is used to save the fault event.

[0036] In one possible design, the domain controller includes one or more of: CDC, MDC, VDC, and T-BOX.

[0037] In a third aspect, a vehicle diagnostic device is provided, which has the function of implementing the method as described in any one of the designs in the first aspect or the second aspect above. The function can be implemented by hardware, or by hardware executing corresponding software. The hardware or software includes one or more modules corresponding to the above functions. In a possible example, the vehicle diagnostic device includes a communication unit (or communication module) and a processing unit (or processing module); the communication unit is used to perform the communication operation in the method as described in any one of the designs in the first aspect or the second aspect above. The processing unit is used to perform the processing operation in the method as described in any one of the designs in the first aspect or the second aspect above.

[0038] In a fourth aspect, a vehicle diagnostic device is provided, comprising a processor and a memory, wherein the memory is coupled to the processor, the memory is used to store computer program code, the computer program code comprises computer instructions, and the processor reads the computer instructions from the memory so that the vehicle diagnostic device executes the method as described in any one of the designs of the first aspect or the second aspect above.

[0039] In one possible design, the vehicle diagnostic device further includes a communication interface, which can be used for the vehicle diagnostic device to communicate with other devices. Exemplarily, the communication interface can be a transceiver, an input / output interface, an interface circuit, an output circuit, an input circuit, a pin or a related circuit, etc.

[0040] In one possible design, the vehicle diagnostic device also includes input and output devices (such as a display screen, audio equipment, etc.), which can be used for the vehicle diagnostic device to perform input and output operations.

[0041] In a fifth aspect, a computer-readable storage medium is provided, wherein the computer-readable storage medium includes a computer program. When the computer program is run on a vehicle diagnostic device, the vehicle diagnostic device executes a method as described in any one of the designs of the first aspect or the second aspect.

[0042] In a sixth aspect, a computer program product is provided, the computer program product comprising: a computer program or instructions, when the computer program or instructions are run on a computer, the computer executes the method as described in any one of the designs of the first aspect or the second aspect above.

[0043] In the seventh aspect, a chip system is provided, comprising at least one processor and at least one interface circuit, wherein the at least one interface circuit is used to perform transceiver functions and send instructions to the at least one processor, and when the at least one processor executes the instructions, the at least one processor executes the method described in any one of the designs in the first aspect or the second aspect above.

[0044] In an eighth aspect, a communication system is provided, comprising a vehicle and a server, wherein the vehicle comprises a vehicle diagnostic device as described in the third aspect or the fourth aspect.

[0045] It should be noted that the technical effects brought about by any design in the above-mentioned second to eighth aspects can refer to the technical effects brought about by the corresponding design in the first aspect, and will not be repeated here. BRIEF DESCRIPTION OF THE DRAWINGS

[0046] Figure 1 A schematic diagram of the architecture of a communication system provided in an embodiment of the present application;

[0047] Figure 2 A schematic diagram of the structure of a first device and a second device provided in an embodiment of the present application;

[0048] Figure 3 A schematic diagram of the structure of another first device and a second device provided in an embodiment of the present application;

[0049] Figure 4 A schematic diagram of the structure of another first device and a second device provided in an embodiment of the present application;

[0050] Figure 5 A schematic diagram of the structure of another first device and a second device provided in an embodiment of the present application;

[0051] Figure 6 A schematic diagram of the structure of another first device and a second device provided in an embodiment of the present application;

[0052] Figure 7 A schematic diagram of the structure of another first device and a second device provided in an embodiment of the present application;

[0053] Figure 8 A schematic diagram of the structure of another first device and a second device provided in an embodiment of the present application;

[0054] Fig. 9 A schematic diagram of the structure of an intelligent diagnosis application provided in an embodiment of the present application;

[0055] Fig.10 A schematic diagram of a vehicle diagnostic method provided in an embodiment of the present application;

[0056] Fig.11 A set of mobile phone interface schematic diagrams provided for embodiments of the present application;

[0057] Fig.12 A schematic diagram of the structure of a log file provided in an embodiment of the present application;

[0058] Fig.13A flowchart of another vehicle diagnostic method provided in an embodiment of the present application;

[0059] Fig.14 A flowchart of another vehicle diagnostic method provided in an embodiment of the present application;

[0060] Fig.15 A schematic diagram of the structure of a vehicle diagnostic device provided in an embodiment of the present application;

[0061] Fig.16 A schematic diagram of the structure of another vehicle diagnostic device provided in an embodiment of the present application. DETAILED DESCRIPTION

[0062] In order to clearly describe the technical solutions of the embodiments of the present application, in the embodiments of the present application, words such as "first" and "second" are used to distinguish the same or similar items with substantially the same functions and effects. Those skilled in the art can understand that words such as "first" and "second" do not limit the quantity and execution order, and words such as "first" and "second" do not necessarily limit the difference.

[0063] In addition, the network architecture and business scenarios described in the embodiments of the present application are intended to more clearly illustrate the technical solutions of the embodiments of the present application, and do not constitute a limitation on the technical solutions provided in the embodiments of the present application. Ordinary technicians in this field can know that with the evolution of network architecture and the emergence of new business scenarios, the technical solutions provided in the embodiments of the present application are also applicable to similar technical problems.

[0064] Vehicle diagnosis is one of the commonly used technical means in the field of fault location in the vehicle industry. The diagnostic instrument is a widely used vehicle diagnostic instrument. The diagnostic instrument can connect to the vehicle's on-board diagnostics (OBD) system through the vehicle communications interface (VCI), and provide various functions such as reading diagnostic trouble codes (DTC), reading vehicle version information, reading data identifiers (DID) of data streams, clearing fault codes, and flashing software to achieve daily diagnosis and maintenance of vehicles. Among them, by reading DTC, the fault code and maintenance suggestions of the problem parts in the vehicle can be obtained. By reading the vehicle version information, the software and hardware version information of the components in the vehicle can be obtained to determine whether the version needs to be flashed. By reading the DID of the data stream, the key information parameters of the components in the vehicle can be obtained. By clearing the fault code, the fault information of the components in the vehicle can be eliminated.

[0065] With the continuous popularization and development of network technology, remote diagnosis is gradually applied to vehicle diagnosis to improve the convenience of diagnosis and maintenance. Among them, remote diagnosis refers to the way to diagnose and repair vehicles by simulating diagnostic instruments on cloud servers to perform basic operations such as remote reading of vehicle information, reading vehicle fault codes, reading freeze frames, clearing fault codes, reading component fault codes, and reading component data streams.

[0066] At present, the remote diagnosis provided by the cloud server and the diagnostic method provided by the diagnostic instrument are based on the unified diagnostic services (UDS) diagnostic capability implemented by the International Organization for Standardization (ISO) 14229-1 specification. The diagnostic database used by both is the open diagnostic data exchange (ODX) diagnostic database. Among them, the ODX diagnostic database is the diagnostic database used by the standard diagnostic instrument developed by the Association for Standardisation of Automation and Measuring Systems (ASAM). During the vehicle development process, the vehicle manufacturer defines the ODX diagnostic database of the components in the vehicle, and then releases it to the manufacturer of the cloud server or diagnostic instrument. The corresponding manufacturer develops the cloud server or diagnostic instrument based on the ODX diagnostic database defined by the vehicle manufacturer. During the life cycle of the vehicle, the cloud server or diagnostic instrument can diagnose the components in the vehicle based on the ODX diagnostic database.

[0067] In the above diagnostic method, the fault code and data stream read only carry a small amount of information when the hardware fails, so this method can solve the fault diagnosis of traditional ECU components in the vehicle. With the continuous development of automotive electronic and electrical architecture, vehicles have evolved from the traditional distributed architecture centered on ECU components to a regional centralized architecture centered on domain controller units (DCU). In a distributed architecture centered on ECU components, each ECU is usually responsible for controlling a single functional unit and is independent of each other. For example, different ECUs control the engine, brakes, doors and other components respectively. Each ECU can be connected together for communication through a controller area network (CAN) bus or a local interconnect network (LIN) bus.

[0068] As the application of electronic and electrical products in the whole vehicle increases, the number of ECUs gradually increases. In order to reduce the cost of the whole vehicle, a regional center architecture centered on the domain controller came into being. Among them, the domain controller can divide the functions of various parts of the vehicle into several areas, such as: power transmission domain, body electronics domain, etc., and then use the powerful multi-core central processing unit (CPU) or graphics processing unit (GPU) to control the functions originally belonging to each ECU in a relatively centralized control domain. The domain controller is no longer a simple single-chip microcomputer or embedded system, but a highly intelligent high-performance computer (HPC) that runs complex operating systems and application software to achieve high-computing applications such as network connection, smart cockpit, smart vehicle control, and smart driving.

[0069] In a distributed architecture centered on a domain controller, the fault problems of the domain controller mainly include hardware faults, software faults, performance reliability problems, etc. The hardware faults of the domain controller can be diagnosed through the above-mentioned diagnostic methods, but the software faults and performance reliability problems of the domain controller are difficult to diagnose through the above-mentioned methods of reading fault codes and data streams. For example: if the domain controller of a vehicle has a problem of slow Internet access, if there is no problem with the hardware of the domain controller, reading fault codes and data streams can only detect that the hardware is fault-free, and cannot diagnose the cause of the slow Internet access.

[0070] Based on this, an embodiment of the present application provides a vehicle diagnostic method, which realizes remote diagnosis of the domain controller in the vehicle by pre-setting an intelligent diagnostic application, and solves problems such as software failures and performance reliability problems of the domain controller that are difficult to diagnose by reading fault codes, data streams, etc.

[0071] The technical solution provided in the embodiments of the present application can be applied to various scenarios for diagnosing intelligent components, such as: in the field of vehicle diagnosis, diagnosing domain controllers and traditional ECUs in vehicles; in the field of Internet of Things diagnosis, diagnosing HPCs with powerful computing power.

[0072] For example, Figure 1 The schematic diagram of the architecture of a communication system for a vehicle diagnostic method provided in an embodiment of the present application is shown. Figure 1 As shown, the communication system 100 includes a first device 101 and a second device 102 .

[0073] The first device 101 is a diagnosed device. Exemplarily, the first device 101 may be a vehicle, an artificial intelligence (AI) device (such as but not limited to a robot, a mechanical dog, etc.), a drone, or other devices. Figure 1 In the figure, the first device 201 is shown as a vehicle. In some embodiments, one or more domain controllers are installed in the first device 101, and the second device 101 can initiate diagnosis of these domain controllers to determine software failures, performance reliability issues, etc. of the domain controllers. Exemplarily, the domain controller may include but is not limited to one or more of a cockpit domain controller (CDC), a vehicle domain controller (VDC), a mobile data center (MDC), a telematics box (T-BOX), etc.

[0074] Among them, CDC is a domain controller for controlling the smart cockpit domain. The smart cockpit domain can integrate various information such as driving information and entertainment information based on the human-computer interaction scene in the cockpit. Exemplarily, the smart cockpit domain includes but is not limited to the head-up display system (HUD), the instrument panel (cockpit) and the in-vehicle infotainment (IVI) system. VDC is a domain controller for controlling the whole vehicle domain (or body domain), the chassis domain, etc. The whole vehicle domain mainly integrates body electronic components, such as but not limited to lights, wipers, central door locks, etc. The chassis domain integrates driving-related functions, such as but not limited to the transmission system, driving system, steering system, braking system, etc. MDC is a domain controller for controlling the autonomous driving domain. The autonomous driving domain integrates relevant functions for realizing autonomous driving, such as but not limited to environmental perception, positioning, path planning, decision control, etc. T-BOX is a domain controller for remote supervision and operation of control equipment. T-BOX can be used as a wireless gateway to provide a remote communication interface for the equipment, and provide various services such as driving trajectory recording and fault monitoring. It is understandable that each domain controller may also have other names, and its name does not constitute a limitation on its function.

[0075] Optionally, one or more traditional ECUs may be installed in the first device 101 , and the second device 101 may also initiate diagnosis of these traditional ECUs.

[0076] The second device 102 may initiate a remote diagnosis of the first device 101. Exemplarily, the second device 102 may be a server, which may be a device or server with computing functions such as a cloud server or a network server. The server may be a single server, a server cluster consisting of multiple servers, or a cloud computing service center.

[0077] In some embodiments, Figure 1 The communication system 100 shown may also include a third device 103. The third device 103 may be used to receive user instructions and send the received user instructions to the second device 102, so that the second device 102 can initiate a diagnosis of the first device 101 according to the user instructions. In some embodiments, the third device 103 may also output (such as displaying on a display screen, broadcasting by a speaker, etc.) the diagnosis result of the first device x, so that the user can know the diagnosis result. Exemplarily, the third device 103 may be various devices such as mobile phones, tablet computers, wearable devices, AI devices, and vehicle-mounted devices. Figure 1 In the figure, the third device 103 is shown as a mobile phone.

[0078] Optionally, the first device 101 and the second device 102, and / or the second device 102 and the third device 103 can communicate via wired communication technology or wireless communication technology. Exemplarily, the wireless communication technology includes but is not limited to at least one of the following: fourth generation (4G) communication technology (e.g., long term evolution (LTE) technology), worldwide interoperability for microwave access (WiMAX) communication technology, fifth generation (5G) communication technology (e.g., new radio (NR) technology), and future mobile communication technology, such as sixth generation (6G) mobile communication technology.

[0079] In some embodiments, the domain controller in the first device 101 has a diagnostic function, which can be used to diagnose one or more domain controllers included in the first device 101, that is, the first device 101 can perform the operation of diagnosing the domain controller. Optionally, the diagnostic function can also be used to diagnose one or more traditional ECUs included in the first device 101. Optionally, the diagnostic function can be implemented by an intelligent diagnostic application (or first application, or intelligent diagnostic module, etc.) deployed on the domain controller.

[0080] It can be understood that the intelligent diagnosis application in the embodiment of the present application can be an application program, or a software module, or a chip, a component, etc.

[0081] In some embodiments, the intelligent diagnostic application can be deployed on all domain controllers included in the first device 101, that is, for each domain controller included in the first device 101, an intelligent diagnostic application can be deployed. Among them, the intelligent diagnostic application deployed on each domain controller can be used to implement the diagnosis of the domain controller where it is located. In this way, there is no need for additional interaction of diagnostic instructions between different domain controllers, which can reduce signaling overhead. Of course, the intelligent diagnostic application deployed on each domain controller can also be used to implement the diagnosis of other domain controllers or traditional ECUs other than the domain controller where it is located, and the embodiments of the present application do not impose specific restrictions on this.

[0082] In other embodiments, the intelligent diagnostic application may also be deployed on some of the domain controllers included in the first device 101, that is, only some of the domain controllers in the first device 101 are deployed with intelligent diagnostic applications. These intelligent diagnostic applications can be used to implement the diagnosis of all domain controllers, traditional ECUs, etc. included in the first device 101. For example: the first device 101 includes domain controller A, domain controller B, domain controller C, and domain controller D, and intelligent diagnostic applications are deployed on domain controllers A and B. The intelligent diagnostic application deployed on domain controller A can be used to implement the diagnosis of domain controllers A and C, and the intelligent diagnostic application deployed on domain controller B can be used to implement the diagnosis of domain controllers B and D. Alternatively, the intelligent diagnostic application deployed on domain controller A can be used to diagnose domain controllers C and D, and the intelligent diagnostic application deployed on domain controller B can be used to diagnose domain controllers A and B. The embodiments of the present application do not specifically limit which intelligent diagnostic application is specifically used to diagnose which domain controllers, traditional ECUs, etc.

[0083] In some other embodiments, the smart diagnostic application can be deployed on a domain controller included in the first device 101, that is, only one smart diagnostic application can be deployed in the first device 101, and the smart diagnostic application can be used to diagnose all domain controllers, traditional ECUs, etc. included in the first device 101, which can reduce the complexity of deploying smart diagnostic applications. In a specific implementation, the smart diagnostic application can be deployed on a smart cockpit. Since the smart cockpit has good computing power, large storage, and can also interact with users, deploying the smart diagnostic application on the smart cockpit can reduce the difficulty of development.

[0084] In this embodiment, Figure 2 A schematic structural diagram of a first device 101 and a second device 102 provided in an embodiment of the present application is shown.

[0085] like Figure 2 As shown, at least one domain controller is deployed in the first device 101, such as domain controller 1, domain controller 2, etc. ( Figure 2 Only two are shown).

[0086] The domain controller 1 is deployed with a communication module 1, which can be used to interact with the second device 102 to receive a diagnostic instruction from the second device 102, and the diagnostic instruction can be used to instruct the intelligent diagnostic application to initiate a diagnosis of the first device 101. Further, the domain controller 1 can send the received diagnostic instruction to the intelligent diagnostic application in the domain controller 2, so that the intelligent diagnostic application can perform a diagnosis based on the diagnostic instruction.

[0087] Among them, an intelligent diagnosis application is deployed on the domain controller 2, and the intelligent diagnosis application can be used to implement diagnosis of all domain controllers included in the first device 101. The intelligent diagnosis application can receive a diagnosis instruction from the communication module 1, and perform a diagnosis of the domain controller included in the first device 101 based on the diagnosis instruction. In some embodiments, the intelligent diagnosis application can receive a diagnosis task from the second device 102 based on the received diagnosis instruction, and perform a diagnosis of the domain controller to be diagnosed included in the first device 102 according to the diagnosis task. Optionally, the intelligent diagnosis application can establish a connection with the second device 102, and the intelligent diagnosis application can receive a diagnosis task from the second device 102 based on the established connection. For example: the intelligent diagnosis application can actively establish a connection with the second device 102 after receiving the diagnosis instruction, or the intelligent diagnosis application has established a connection with the second device 102 before receiving the diagnosis instruction. The embodiment of the present application does not impose any restrictions on the timing of establishing the connection.

[0088] Optionally, the connection established above may be a connection established based on Hypertext Transfer Protocol over Secure Socket Layer (HTTPS), and the second device 102 may send the diagnostic task to the first device 101 based on a Representational State Transfer (REST) ​​interface. Of course, the connection may also be established based on other protocols.

[0089] In some embodiments, a data acquisition module can also be deployed on the domain controller 2. The data acquisition module can be used to collect the data to be diagnosed of the domain controller to be diagnosed according to the diagnostic task, and send the data to be diagnosed to the intelligent diagnostic application. The intelligent diagnostic application can diagnose the domain controller to be diagnosed based on the data to be diagnosed.

[0090] The second device 102 includes a remote diagnosis service, a communication module 2 and the like.

[0091] The remote diagnostic service may be used to initiate diagnosis of the first device 101, such as but not limited to diagnosis of various components such as a domain controller and a traditional ECU included in the first device 101. In some embodiments, the remote diagnostic service may initiate diagnosis of the first device 101 on a regular or periodic basis. In other embodiments, the remote diagnostic service may be based on the operation of the operation and maintenance personnel, or Figure 1 The instructions of the third device 103 shown, etc., initiate the diagnosis of the first device 101. The embodiment of the present application does not specifically limit the timing of initiating the diagnosis of the first device 101 by the remote service.

[0092] In some embodiments, the remote diagnostic service may be used to generate one or more of diagnostic instructions and diagnostic tasks, and send the diagnostic instructions, diagnostic tasks, etc. to the first device 101 to implement diagnosis of the first device 101 .

[0093] The communication module 2 may be used to receive a diagnostic instruction from a remote diagnostic service and send the diagnostic instruction to the first device 101. In some embodiments, the communication module 2 may also be used to receive one or more of a diagnostic result, data to be diagnosed, etc. from the first device 101 and send one or more of the diagnostic result, data to be diagnosed, etc. to the remote diagnostic service.

[0094] Understandably, Figure 2 The example is that the domain controller receiving the diagnostic instruction is different from the domain controller deploying the intelligent diagnostic application. In other embodiments, the domain controller receiving the diagnostic instruction and the domain controller deploying the intelligent diagnostic application can also be the same, so that the diagnostic instruction does not need to be transmitted between different domain controllers, which can save signaling overhead.

[0095] In this embodiment, Figure 3 FIG. 1 is a schematic diagram showing the structure of another first device 101 and a second device 102 provided in an embodiment of the present application. Figure 3 As shown, the domain controller 2 is deployed with the communication module 1 and the intelligent diagnosis application at the same time. The domain controller 2 can directly receive the diagnosis instruction from the second device 102 through the communication module 1, and then send the diagnosis instruction to the intelligent diagnosis application. Correspondingly, the intelligent diagnosis application receives the diagnosis task from the second device 102 according to the diagnosis instruction, and diagnoses the domain controller in the first device 101 based on the diagnosis task. In this way, compared with Figure 2 In the architecture shown, the diagnostic instructions do not need to be transmitted between domain controller 1 and domain controller 2, which can save signaling overhead. Figure 3 For an introduction to each module shown, please refer to Figure 2 The introduction of the corresponding module is shown.

[0096] In some embodiments, the domain controller in the first device 101 can use the message queuing telemetry transport (MQTT) protocol to receive diagnostic instructions from the second device 102. Among them, the MQTT protocol is a communication protocol based on publishing and subscription, and its system architecture includes an MQTT client and an MQTT server. The MQTT message contains two parts: a topic and a preload. The MQTT client can register or listen to the corresponding topic on the MQTT server.

[0097] In some embodiments, the naming convention of the topic in the MQTT message can be: V1 / ${svcType}-${msgType} / ${deviceID}, where "svcType" and "msgType" can be used to distinguish different instruction types, and "deviceID" can refer to the identification (identity, ID) of the first device 101, which can be mapped to an Internet Protocol (IP) address so that the second device 102 can find the first device 101.

[0098] The payload part may be used to carry the body of the MQTT message, and the parameters of the specific diagnostic instruction may be carried in the payload part in a data format such as JSON.

[0099] In this embodiment, combined with Figure 2 The structure shown, Figure 4 A schematic structural diagram of another first device 101 and a second device 102 provided in an embodiment of the present application is shown.

[0100] like Figure 4 As shown, such as Figure 2 The communication module 1 included in the first device 101 shown may include an MQTT client module, which may enable the domain controller 1 to act as an MQTT client and receive diagnostic instructions from the second device 102 based on the MQTT protocol.

[0101] Such as Figure 2 The communication module 2 included in the second device 102 shown may include an MQTT distributor and a file service module. The MQTT distributor may send a diagnostic instruction to the first device 101 based on the MQTT protocol. The file service module may receive one or more of a diagnostic result and data to be diagnosed from the first device 101.

[0102] In some embodiments, the protocol used by the domain controller may be different from the MQTT protocol. For example, the domain controller may use the Scalable Service-Oriented Middleware over IP (SOMEIP) protocol for communication. Figure 4 As shown, an MQTT message agent may also be deployed on the domain controller 1, and the MQTT message agent may be used to convert the MQTT message into a message format specified by the protocol adopted by the domain controller, such as a SOMEIP message or a message in another format. The MQTT message agent may also send the diagnostic instruction after the message format conversion to the intelligent diagnostic application.

[0103] In some embodiments, Figure 4 As shown, one or more traditional ECUs and unified diagnostic services (UDS) agents may also be deployed on the first device 101, and the intelligent diagnostic application can also diagnose these traditional ECUs. For example: after receiving the diagnostic task, if the intelligent diagnostic application determines that the traditional ECU needs to be diagnosed according to the diagnostic task, the intelligent diagnostic application can read the fault code of the traditional ECU through the UDS agent and diagnose the traditional ECU according to the fault code.

[0104] about Figure 4 For an introduction to the other modules shown, refer to Figure 2 The following table shows the introduction of the corresponding module.

[0105] Understandably, Figure 4 The structure shown is based on the combination of Figure 2 The structure shown is taken as an example. Similarly, combining Figure 3 The structure shown, Figure 5 FIG. 1 is a schematic diagram showing the structure of another first device 101 and a second device 102 provided in an embodiment of the present application. Figure 5 As shown, such as Figure 3 The communication module 1 shown may include an MQTT client module, which may enable the domain controller 2 to act as an MQTT client and receive diagnostic instructions from the second device 102 based on the MQTT protocol. Figure 5 For an introduction to the other modules shown, refer to Figure 3 , Figure 4 The following table shows the introduction of the corresponding module.

[0106] It can be understood that the above embodiments are all based on the example of the first device 101 having a diagnostic function to perform diagnostic operations. In other embodiments, the second device 102 may have a diagnostic function, which can be used to diagnose one or more controllers, traditional ECUs, etc. included in the first device 101, that is, the second device 102 can perform diagnostic operations on the domain controller included in the first device 101. Optionally, the diagnostic function can also be implemented by an intelligent diagnostic application deployed in the second device 102.

[0107] In this embodiment, Figure 6 A schematic structural diagram of another first device 101 and a second device 102 provided in an embodiment of the present application is shown.

[0108] like Figure 6 As shown, at least one domain controller is deployed in the first device 101, such as domain controller 1, domain controller 2, etc. ( Figure 6 Only two are shown).

[0109] Wherein, a communication module 1 is deployed on the domain controller 1, and the communication module 1 can be used to interact with the second device 102, and receive a diagnostic instruction from the second device 102, and the diagnostic instruction can be used to instruct to initiate a diagnosis of the domain controller to be diagnosed. Further, the communication module 1 can send the received diagnostic instruction to the domain controller to be diagnosed, so that the domain controller to be diagnosed can send its own data to be diagnosed to the second device 102 according to the diagnostic instruction.

[0110] Taking the domain controller to be diagnosed as domain controller 2 as an example, a data acquisition module is deployed in domain controller 2, and domain controller 2 can collect its own data to be diagnosed through the data acquisition module based on the diagnostic instruction from communication module 1. Further, domain controller 2 can upload the data to be diagnosed to the second device 102, so that the second device 102 can diagnose domain controller 2 based on the data to be diagnosed.

[0111] Optionally, in this embodiment, each domain controller included in the first device 101 may have the function of receiving and parsing diagnostic instructions from the communication module 1, and this function may be implemented by software, hardware, or a combination of software and hardware.

[0112] Optionally, in this embodiment, a data acquisition module may be deployed for each domain controller included in the first device 101, so that each domain controller can collect its own data to be diagnosed through the data acquisition module based on the diagnostic instruction after receiving the diagnostic instruction to achieve self-diagnosis. Alternatively, a data acquisition module may be deployed only on one or some of the domain controllers, and the data acquisition module may be used to collect and upload the data to be diagnosed of the domain controller to be diagnosed to the second device 102.

[0113] It can be understood that the data to be diagnosed of the domain controller to be diagnosed can be collected by its own data acquisition module and uploaded to the second device 102, or it can be collected by data acquisition modules in other domain controllers except the domain controller to be diagnosed and uploaded to the second device 102. The embodiment of the present application does not impose specific restrictions on this.

[0114] The second device 102 includes a remote diagnostic service, a communication module 2, and an intelligent diagnostic application. The intelligent diagnostic application can be used to diagnose the domain controller included in the first device 101. In some embodiments, the intelligent diagnostic application can receive the to-be-diagnosed data of the to-be-diagnosed domain controller from the first device 101, diagnose the to-be-diagnosed domain controller based on the to-be-diagnosed data, and obtain a diagnostic result.

[0115] about Figure 6 For an introduction to the other modules shown, refer to Figure 2 Corresponding introduction of the modules shown.

[0116] Similarly, with Figure 3 The structure shown is similar to Figure 6 In the structure shown, the communication module 1 can also be deployed on the domain controller 2. Figure 4 , Figure 5 The structure shown is similar to Figure 6 The structure shown can also be presented as Figure 7 , Figure 8 The form shown. Figure 7 , Figure 8 In the structure shown, when the second device 102 diagnoses the traditional ECU, the second device 102 can send a diagnostic instruction to the UDS agent. Correspondingly, after receiving the diagnostic instruction, the UDS agent reads the fault code of the traditional ECU according to the diagnostic instruction and sends the read ECU fault code to the second device 102.

[0117] Understandably, Figure 7 , Figure 8 In the illustrated structure, the MQTT client module and the UDS agent are deployed in the same domain controller as an example. In other embodiments, the MQTT client module and the UDS agent can also be deployed in different domain controllers. The embodiment of the present application does not limit the location where the UDS is deployed. Optionally, the fault code read by the UDS can be directly uploaded to the second device 102 by the UDS, or forwarded to the second device 102 by other devices.

[0118] about Figure 7 , Figure 8 For an introduction to each module shown, please refer to Figure 4 , Figure 5 , Figure 6 Introduction to the corresponding modules in etc.

[0119] Optionally, in the above embodiment, when the intelligent diagnosis application is deployed on the second device 102, the second device 102 does not need to issue a diagnosis task to the first device 101, and can directly carry the content of the diagnosis task in the diagnosis instruction. This can make the development of the first device 101 simpler. Of course, the second device 102 can also diagnose the first device 101 by issuing a diagnosis instruction and a diagnosis task, and the embodiment of the present application does not limit this.

[0120] It is understandable that the embodiment of the present application does not impose any specific restrictions on the domain controller where the communication module 1 described above is deployed. For example, the communication module 1 can be deployed on a T-BOX or on other domain controllers other than the T-BOX. Figures 2 to 8 In the illustrated structure, only one communication module 1 is deployed on the first device 101. The embodiment of the present application does not specifically limit the number of communication modules 1, and the communication modules 1 can also be deployed on multiple domain controllers included in the first device 101.

[0121] For example, taking the deployment of the intelligent diagnosis application in the first device 101 as an example, Fig. 9 A schematic diagram of the structure of an intelligent diagnosis application provided in an embodiment of the present application is shown.

[0122] like Fig. 9 As shown, the intelligent diagnosis application includes a communication module 3, a diagnosis database, a diagnosis process executor, and a data analysis module.

[0123] The communication module 3 is used to receive a diagnosis instruction, and based on the diagnosis instruction, receive a diagnosis task from the second device 102. The communication module 3 can also be used to upload one or more of a diagnosis result and data to be diagnosed to the second device 102.

[0124] The diagnostic database may be used to store the diagnostic process from the second device 102. The diagnostic process stored in the diagnostic database may be synchronized with the diagnostic process in the second device 102. Optionally, the diagnostic process stored in the diagnostic database may be obtained from the second device 102 periodically, or may be obtained from the second device 102 when the second device 102 triggers a diagnosis of the first device 101. The embodiment of the present application does not impose any specific restrictions on the timing of obtaining the diagnostic process from the second device 102.

[0125] The diagnosis process executor may obtain analysis data from the data analysis module based on the diagnosis process stored in the diagnosis database, and obtain a diagnosis result based on the analysis data.

[0126] The data analysis module may include one or more of a dot log analysis module, a performance statistics module, an abnormal log retrieval module, and an instruction interaction module. Among them, the dot log analysis module can analyze the dot log. The performance statistics module can obtain the cracking point of the performance based on the dot log statistical analysis. The abnormal log retrieval module can be used to search the system log and find abnormal information in the system log, such as errors, alarms, etc. The instruction interaction module can be used to interact with other domain controllers, traditional ECUs and other components contained in the first device 101 through various instructions such as SOMEIP and service-oriented vehicle diagnostics protocol (SOVD) to obtain fault code information.

[0127] In some embodiments, Fig. 9 The intelligent diagnosis application shown may also include a human-computer interaction module. If human-computer interaction operations are required during the diagnosis process, the human-computer interaction module may provide a human-computer interaction interface (such as an interface, an audio module, etc.) to interact with the user, prompt the user to perform operations, and record the user's operation results, so as to diagnose the first device 101 according to the user's operation results.

[0128] Optionally, when the intelligent diagnosis application is deployed on the second device 102, the intelligent diagnosis application may include Fig. 9 More or fewer modules are shown, for example, the human-computer interaction module and the instruction interaction module may not be included. The functions of each module may be different. For example, when the intelligent diagnosis application is deployed on the second device 102, the communication module 3 may be used to send at least one of a diagnosis instruction and a diagnosis task to the first device 101. It may also be used to receive at least one of a diagnosis result and data to be diagnosed from the first device 101.

[0129] Understandably, Figures 2 to 9 The structure shown is obtained based on functional division, and there may be other division methods in actual application, for example: the intelligent diagnosis application and remote diagnosis service included in the second device 102 can also be divided into one functional module.

[0130] In the following, the first device 101 is a vehicle, the second device 102 is a server, and the third device 103 is a mobile phone. Fig.10 FIG. 1 is a flow chart of a vehicle diagnostic method provided by an embodiment of the present application. Fig.10 As shown, the method comprises the following steps:

[0131] S1001: The server sends a diagnostic instruction to the first domain controller. Correspondingly, the first domain controller receives the diagnostic instruction from the server.

[0132] Among them, the first domain controller can be one or more of the domain controllers included in the vehicle, and the vehicle can include at least one component, and the at least one component includes at least one domain controller. It can be understood that the functions of multiple traditional ECUs can be centralized and controlled in a controller with powerful computing power, and such a controller can be called a domain controller. The domain controller can also be understood as an ECU with powerful functions (such as computing power, resources, etc.). Exemplarily, the domain controller may include but is not limited to one or more of CDC, VDC, Mobile Data Center (MDC), T-BOX, etc. Optionally, the at least one component may also include at least one traditional ECU.

[0133] The diagnostic instruction may be used to initiate diagnosis of a component to be diagnosed, and the component to be diagnosed may be one or more of at least one component included in the vehicle. Optionally, the component to be diagnosed may be a domain controller and / or a traditional ECU.

[0134] In some embodiments, the first domain controller may be deployed with an MQTT client, and the first domain controller may receive diagnostic instructions from a server based on the MQTT protocol.

[0135] In some other embodiments, the second domain controller may serve as an MQTT client, and the second domain controller may receive a diagnostic instruction from the server based on the MQTT client, and send the received diagnostic instruction to the first domain controller. The second domain controller may belong to at least one domain controller included in the vehicle, and the second domain controller may be a domain controller different from the first domain controller.

[0136] It can be understood that the above embodiments all take the example of the domain controller in the vehicle receiving the diagnostic instructions from the server based on the MQTT protocol. In other embodiments, the domain controller in the vehicle may also receive the diagnostic instructions from the server based on other protocols.

[0137] In some embodiments, the server may execute step S1001 and subsequent steps according to the operation of the operation and maintenance personnel. For example, the operation and maintenance personnel may log in to the system corresponding to the remote diagnostic service in the server, enter the vehicle identification number (VIN) of the vehicle, and initiate a diagnosis of the vehicle. After the server receives the operation of the operation and maintenance personnel, in response to the operation, the server may determine the IP address of the vehicle according to the VIN of the vehicle, and send a diagnostic instruction to the vehicle according to the IP address. Accordingly, the vehicle may receive the diagnostic instruction through the first domain controller.

[0138] In other embodiments, the server may receive a user instruction from a mobile phone, and in response to the user instruction, the server may execute step S1001 and subsequent steps. For example, a mobile phone may be installed with an application for triggering vehicle diagnosis, and the user may trigger the diagnosis of the vehicle through the application. Fig.11 A schematic diagram of a mobile phone interface provided in an embodiment of the present application is shown.

[0139] like Fig.11 As shown in (1), the mobile phone can display an application interface 1100, and the application interface 1100 can include a button (or control, etc.) for triggering vehicle diagnosis, such as a start diagnosis button 1101. The mobile phone detects an operation such as a user triggering the start diagnosis button 1101. In response to the operation, the mobile phone sends an instruction to the server to diagnose the vehicle. Correspondingly, after receiving the instruction from the mobile phone, the server sends a diagnostic instruction to the vehicle according to the instruction.

[0140] Optionally, the application interface 1100 can also display one or more information such as the vehicle's VIN, owner information, diagnostic fields (such as smart cockpit, body control, network communication, smart driving, etc.), and the mobile phone can also send this information to the server so that the server can confirm which specific components of which vehicle are to be diagnosed.

[0141] Optionally, during the vehicle diagnosis process, the phone can also present information such as Fig.11 The application interface 1110 shown in (2) is used to facilitate the user to confirm the progress of the vehicle diagnosis (such as the current progress is 70%, and it is expected to be completed in 3 minutes), precautions (such as: during vehicle diagnosis, please keep the vehicle still and power on and put it in P gear), etc. Among them, the application interface 1110 can also include one or more of the background execution button 1111 and the cancel button 1112. The background execution button 1111 can be used to execute the vehicle diagnosis process in the background, so as to avoid affecting the user's use of the mobile phone. The cancel button 1112 can be used to cancel the vehicle diagnosis.

[0142] In some other embodiments, the server may also periodically or regularly initiate vehicle diagnosis, and then execute step S1001 and subsequent steps according to its own initiation operation. It can be understood that the embodiment of the present application does not impose any restrictions on the timing of the server initiating vehicle diagnosis.

[0143] S1002: The first domain controller obtains the to-be-diagnosed data of the to-be-diagnosed component according to the diagnosis instruction.

[0144] The data to be diagnosed is used to diagnose the component to be diagnosed.

[0145] In some embodiments, the data to be diagnosed may include at least one type of controller area network (CAN) snapshot, log file, and fault code. Optionally, when the component to be diagnosed is a domain controller, the data to be diagnosed may include at least one type of CAN snapshot and log file. In this way, by collecting the data to be diagnosed of the domain controller, such as CAN snapshots, log files, etc., and analyzing these files, the diagnosis of software failures, performance reliability problems, etc. of the domain controller can be achieved. For example: If the domain controller of the vehicle has a problem of slow Internet access, by collecting CAN snapshots and log files containing various information such as the network rate, network format, and chip parameters of the domain controller, it is analyzed that the slow Internet access is caused by parameter settings, and the specific cause of the slow Internet access can be diagnosed.

[0146] When the component to be diagnosed is a traditional ECU, the data to be diagnosed may be a fault code. In this way, the diagnosis of the hardware fault of the traditional ECU can be realized. Moreover, for different types of components to be diagnosed, different types of data to be diagnosed are obtained, so that the diagnosis of different types of components can be realized.

[0147] Among them, the CAN snapshot can be generated based on the collected CAN data. In this way, instead of uploading the original CAN data to the server, the generated CAN snapshot is uploaded to the server, which can save the vehicle's communication bandwidth and signaling overhead.

[0148] In some embodiments, the log file may include one or more of a system log and a dot log. The system log is used to record the running information (or running log) of the software system of the component to be diagnosed, and the dot log is used to record the information of the fault event that occurs during the operation of the software system of the component to be diagnosed, which can be used to characterize the record when the fault occurs, the state of the component to be diagnosed, etc. Optionally, since there is no log file for the traditional ECU, but there is a log file for the domain controller, the components to be diagnosed described in the part about the log introduction can all refer to the domain controller to be diagnosed, which is uniformly described here.

[0149] Exemplarily, the above-mentioned fault events may include, but are not limited to, software failures, process overflows, performance monitoring, network detection, and other fault events that may be included in various scenario-type faults. Among them, scenario-type faults may refer to fault scenarios that are divided according to factors such as fault type and fault field and correspond to fixed diagnostic processes, such as power loss fault scenarios, etc. Optionally, one or more different fault events may be included in a scenario-type fault, that is, it may correspond to one or more different dot logs. In this way, when a scenario-type fault occurs, the vehicle can be quickly diagnosed based on the dot log corresponding to the scenario-type fault.

[0150] In some embodiments, the dot log can adopt a preset packaging format. In this way, the logs recording the fault events of the components to be diagnosed all adopt a unified format, which can quickly identify various data such as whether the fault occurs, the frequency of occurrence, and key information when it occurs, which can facilitate the analysis of vehicle faults and improve diagnostic efficiency.

[0151] For example, Fig.12 A schematic diagram of a preset encapsulation format provided in an embodiment of the present application is shown. Fig.12 As shown, the preset encapsulation format includes a first field, a second field, a third field, and a fourth field. Among them, the first field can be used to save the identification of the component to be diagnosed, and the first field can be used as a message header. The second field can be used to save the identification of the dot log, and optionally, the identification of the dot log can be globally unique. The third field can be used to save the occurrence time of the fault event recorded in the dot log, and the fourth field can be used to save the fault event. Optionally, the fourth field can adopt a key-value format or other formats. In this way, the preset encapsulation format adopts a json structure, which can make it easier for operation and maintenance personnel to understand and analyze the data to be diagnosed when diagnosing the vehicle.

[0152] Based on the above technical solution, the domain controller in the vehicle can receive a diagnostic instruction from the server for initiating diagnosis of the component to be diagnosed in the vehicle, and then the domain controller can obtain the diagnostic data of the component to be diagnosed according to the diagnostic instruction, and the diagnostic data can be used to diagnose the component to be diagnosed. If the component to be diagnosed can be a domain controller to be diagnosed, etc., the diagnosis of the domain controller in the vehicle is realized, which can solve the problems of software failures, performance reliability problems of the domain controller in the vehicle, etc., which are difficult to diagnose by reading fault codes, data streams, etc.

[0153] In some embodiments, the first domain controller has a diagnostic function, and the diagnostic instruction can be specifically used to instruct the first domain controller to initiate a diagnosis of the vehicle. Optionally, the diagnostic function of the first domain controller can be implemented by an intelligent diagnostic application deployed in the first domain controller. For an introduction to the intelligent diagnostic application, refer to the above description. In this embodiment, Fig.10 Step S1002 shown can be specifically implemented as follows: Fig.13 Steps S1003 to S1004 are shown.

[0154] S1003: The first domain controller receives a diagnosis task from the server according to the diagnosis instruction.

[0155] For the specific implementation of receiving diagnostic tasks according to diagnostic instructions, please refer to Figure 2 The relevant implementation is shown.

[0156] Optionally, in this embodiment, the diagnostic task may be used to indicate one or more of which component to diagnose, which data to be diagnosed is obtained, which diagnostic process to use for diagnosis, etc.

[0157] S1004: The first domain controller obtains data to be diagnosed according to the diagnosis task.

[0158] Optionally, in this embodiment, the diagnostic task carries one or more of the identification of the component to be diagnosed, the indicator item to be diagnosed, the diagnosis type, the identification of the diagnostic process, and the time period in which the data to be diagnosed is located. The first domain controller can obtain the data to be diagnosed based on one or more of the identification of the component to be diagnosed, the indicator item to be diagnosed, and the time period in which the data to be diagnosed is located, etc., carried in the diagnostic task.

[0159] In some embodiments, when the component to be diagnosed is a traditional ECU, the diagnostic task may only carry the identifier of the component to be diagnosed. When the component to be diagnosed is a domain controller, the diagnostic task may carry the identifier of the component to be diagnosed, the indicator item to be diagnosed, the diagnosis type, the identifier of the diagnostic process, and the time period of the data to be diagnosed.

[0160] Among them, the identification of the component to be diagnosed can be used by the first domain controller to determine which component is the component to be diagnosed, that is, which component to diagnose. The indicators to be diagnosed can be used by the first domain controller to determine which indicators to diagnose specifically, such as indicators that may include but are not limited to central control screen freezes, camera unavailability, speaker amplifier, battery problems, network speed, process crashes, disk flushing failures, memory overflows, and other indicators that may be related to the fault. The time period in which the data to be diagnosed is located can be used by the first domain controller to determine which time period to diagnose the data. For example, the time period can be a time period adjacent to the time when the fault occurred.

[0161] In some embodiments, the diagnosis type can be used to determine whether human-computer interaction is required during the diagnosis of the component to be diagnosed. For example: If the diagnosis type is user experience fault diagnosis, it can be determined that human-computer interaction is required during the diagnosis of the component to be diagnosed. At this time, the vehicle can interact with the user through the human-computer interaction interface. For example: Taking the human-computer interaction interface as the central control screen as an example, the vehicle can pop up an authorization box through the central control screen, and after obtaining the user's authorization through the authorization box, output the corresponding inspection items. Taking the inspection item as sound as an example, the user can be guided to play a piece of audio and confirm whether the user can hear it, and obtain the user's operation record and results.

[0162] If the diagnosis type is not user experience fault diagnosis, such as scenario fault diagnosis, log fault diagnosis, etc., it can be determined that no human-computer interaction is required during the diagnosis of the component to be diagnosed.

[0163] The identifier of the diagnostic process can be used by the first domain controller to determine to perform a diagnosis based on various diagnostic processes. In some examples, the first domain controller can receive the identifier of the diagnostic process from, for example, Fig. 9 The first domain controller searches for the corresponding diagnostic process in the diagnostic database shown. If found, subsequent diagnostic operations are performed based on the found diagnostic process. If not found, the first domain controller can obtain the corresponding diagnostic process from the server based on the received diagnostic process identifier, and then perform subsequent diagnostic operations based on the obtained diagnostic process.

[0164] In some embodiments, the diagnostic process only specifies the order of the indicator items of the components that need to be diagnosed to handle a certain fault, but does not specify whether human-computer interaction is required in the process of diagnosing the component. For example: for a certain fault, it is necessary to detect 6 indicator items of 3 domain controllers (such as domain controller 1, domain controller 2, and domain controller 3), of which two indicator items of each domain controller need to be detected, such as indicator item 1 and indicator item 2 of domain controller 1, indicator item 3 and indicator item 4 of domain controller 2, and indicator item 5 and indicator item 6 of domain controller 3. The first step: it is necessary to detect indicator item 1 of domain controller 1, the second step is to detect indicator item 4 of domain controller 2, the fourth step is to detect indicator item 5 of domain controller 3, and so on, until the indicator items of all domain controllers to be detected are detected. The above-mentioned diagnostic steps are the diagnostic process.

[0165] Optionally, in this embodiment, the diagnosis task may carry both the diagnosis type and the diagnosis process.

[0166] In other embodiments, the diagnostic process not only specifies the order of the index items of the components that need to be diagnosed to handle a certain fault, but also specifies whether human-computer interaction is required in the process of diagnosing the components to be diagnosed, how to perform human-computer interaction, etc. For example: diagnosing a certain fault requires detecting three index items of two domain controllers (domain controller 4, domain controller 5), among which index item A and index item B of domain controller 4, and index item C of domain controller 5 need to be detected. Step 1: It is necessary to detect index item A of domain controller 4. When detecting index item A, a pop-up window is required to obtain user authorization and pop up index item A to obtain user operation records and results. Step 2: It is necessary to detect index item C of domain controller 5. When detecting index item C, no human-computer interaction is required. And so on. The aforementioned diagnostic steps are the diagnostic process. In this embodiment, the component to be diagnosed can be diagnosed based only on the diagnostic process.

[0167] In this embodiment, the diagnostic type and the diagnostic process represented by the identifier of the diagnostic process may correspond. Different diagnostic types may correspond to different diagnostic processes. For example: if the diagnostic type is user experience fault diagnosis, the diagnostic process includes the human-computer interaction process. If the diagnostic type is not user experience fault diagnosis, the diagnostic process may not include the human-computer interaction process.

[0168] Optionally, in this embodiment, the diagnostic task may carry only one of the identifiers of the diagnostic type and the diagnostic process.

[0169] In some embodiments, after the first domain controller executes step S1004, Fig.13 The method shown may further include steps S1005 to S1006.

[0170] S1005: The first domain controller diagnoses the component to be diagnosed according to the diagnosis task and the data to be diagnosed.

[0171] Optionally, the first domain controller may determine a specific diagnostic process according to the diagnostic process, diagnostic type, etc. carried in the diagnostic task, and use the diagnostic process to analyze the data to be diagnosed to perform diagnosis on the component to be diagnosed.

[0172] In some embodiments, the first domain controller may adopt different analysis strategies for different types of log files contained in the data to be diagnosed. Taking the log file as a dot log as an example, the first domain controller may analyze the dot log based on the diagnostic process. If it is determined whether the indicator items in the dot log meet the corresponding threshold conditions, it is determined whether the corresponding fault occurs. Since the format of the dot log is unified, it can be parsed into data, so that the vehicle can quickly complete the diagnosis. Optionally, when the diagnosis type is scenario-based fault diagnosis, the log file obtained is a dot log. Since the format of the dot log is unified, this can achieve rapid diagnosis of scenario-based faults. Of course, under this embodiment, the vehicle can also choose to upload the dot log to the server for analysis, and the embodiments of the present application are not limited to this.

[0173] Taking the log file as a system log as an example, the first domain controller can upload the system log to the server, and the server or operation and maintenance personnel will analyze the system log based on the diagnostic process. Since the system log is a running log with an inconsistent format and unable to parse the data, it is difficult for the vehicle to analyze the log. You can choose to upload it to the server for operation and maintenance personnel to search and analyze it. Optionally, when the diagnostic type is log-type fault diagnosis, the obtained log file is a system log, so that the diagnosis of log-type faults can be realized.

[0174] S1006. The first domain controller sends the diagnosis result to the server.

[0175] In some embodiments, the first domain controller may also send the acquired data to be diagnosed to the server. The server may verify the diagnosis result from the vehicle based on the received data to be diagnosed, the diagnosis result, etc., to determine the accuracy of the vehicle diagnosis result.

[0176] In other embodiments, the server has a diagnostic function. Optionally, the diagnostic function of the server can be implemented by an intelligent diagnostic application deployed in the server, and the intelligent diagnostic application can be used to diagnose the component to be diagnosed based on the data to be diagnosed.

[0177] about Fig.13 For a description of the other steps shown, refer to Fig.10 An introduction to the corresponding steps.

[0178] In this embodiment, the diagnostic instruction described in step S1001 may directly carry the content of the diagnostic task. For example, the diagnostic instruction may carry one or more of the identifier of the component to be diagnosed, the indicator item to be diagnosed, and the time period in which the data to be diagnosed is located. For the introduction of these parameters, please refer to the above. Of course, the aforementioned diagnostic instruction may also directly carry the diagnostic identifier, and accordingly, after receiving the diagnostic identifier, the vehicle can determine which data of which component to upload, etc.

[0179] Illustratively, Table 1 shows an example of a diagnostic instruction provided in an embodiment of the present application.

[0180] Table 1

[0181]

[0182]

[0183] As shown in Table 1, "compID" is the identifier of the component to be diagnosed, "fileType" is the log type, and "logStartTime, logEndTime" are the start and end times of the log respectively.

[0184] In this embodiment, Fig.10 The steps shown may also include Fig.14 Steps S1007 to S1008 are shown.

[0185] S1007: The first domain controller sends the data to be diagnosed to the server. Correspondingly, the server receives the data to be diagnosed from the first domain controller.

[0186] In some embodiments, the first domain controller may be a component to be diagnosed. That is, when the server performs a diagnostic operation, the component to be diagnosed on the vehicle side may directly send its own data to be diagnosed to the server.

[0187] S1008. The server diagnoses the component to be diagnosed according to the data to be diagnosed.

[0188] Optionally, the server may also determine a specific diagnostic process according to the diagnostic flow, diagnostic type, etc., and use the diagnostic process to analyze the data to be diagnosed to implement diagnosis of the component to be diagnosed.

[0189] about Fig.14 For a description of the other steps shown, refer to Fig.10 An introduction to the corresponding steps.

[0190] Based on the above technical solution, the server diagnoses the components on the vehicle side according to the data of the components to be diagnosed obtained from the vehicle side, which can make the development of the vehicle side simpler.

[0191] In some embodiments, after the vehicle diagnosis is completed and the diagnosis result is obtained, the server can also send the diagnosis result to the mobile phone. Correspondingly, after receiving the diagnosis result, the mobile phone can also output the diagnosis result. Fig.10 FIG. 1 is a schematic diagram showing an interface for outputting diagnostic results of a mobile phone provided in an embodiment of the present application. Fig.11 As shown in (3), the mobile phone can display the diagnosis results of the vehicle through the application interface 1120, etc.

[0192] The above mainly introduces the solution provided by the embodiment of the present application from the perspective of method. It can be understood that in order to realize the above functions, the vehicle diagnostic device includes hardware structures and / or software modules corresponding to the execution of each function. In combination with the units and algorithm steps of each example described in the embodiment disclosed in this application, the embodiment of the present application can be implemented in the form of hardware or a combination of hardware and computer software. Whether a function is executed in hardware or computer-driven hardware depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered to exceed the scope of the technical solution of the embodiment of the present application.

[0193] The present application is an embodiment that can divide the functional modules of the vehicle diagnostic device according to the above method example. For example, each functional module can be divided according to each function, or two or more functions can be integrated into one processing unit. The above integrated unit can be implemented in the form of hardware or in the form of software functional modules. It should be noted that the division of units in the embodiment of the present application is schematic and is only a logical functional division. There may be other division methods in actual implementation.

[0194] like Fig.15FIG. 1 is a schematic diagram of a vehicle diagnostic device provided in an embodiment of the present application. The vehicle diagnostic device 1500 can be used to implement the methods described in the above method embodiments. Exemplarily, the vehicle diagnostic device 1500 may specifically include: a processing unit 1501 and a communication unit 1502 .

[0195] As a possible example, the vehicle diagnostic device 1500 is a vehicle, or a module (such as a chip) used in a vehicle, for example, the processing unit 1501 is used to support the vehicle diagnostic device 1500 to perform the following Figures 1 to 14 The communication unit 1502 is used to support the vehicle diagnostic device 1500 to perform the processing function as described in any one of the above. Figures 1 to 14 A communication function performed by a vehicle as described above.

[0196] As another possible example, the vehicle diagnostic device 1500 is a server, or a module (such as a chip) used in a server, for example, the processing unit 1501 is used to support the vehicle diagnostic device 1500 to perform the following Figures 1 to 14 The communication unit 1502 is used to support the vehicle diagnostic device 1500 to perform the following processing functions: Figures 1 to 14 The communication function performed by any of the servers described above.

[0197] Optional, Fig.15 The vehicle diagnostic device 1500 shown may also include a storage unit 1503, which stores a program or instruction. When the processing unit 1501 executes the program or instruction, Fig.15 The vehicle diagnostic device 1500 shown can execute the method described in the above method embodiment.

[0198] Optional, Fig.15 The vehicle diagnostic device 1500 shown may also include an input-output unit (not shown in the figure), which may be used to provide a human-computer interaction interface to achieve human-computer interaction.

[0199] Fig.15 The technical effects of the vehicle diagnostic device 1500 shown can refer to the technical effects described in the above method embodiment, and will not be repeated here.

[0200] The processing unit 1501 may be a processor or a controller, such as a CPU, a general-purpose processor, an application specific integrated circuit (ASIC), a field programmable gate array (FPGA) or other programmable logic devices, transistor logic devices, hardware components or any combination thereof. It may implement or execute various exemplary logic blocks, modules and circuits described in conjunction with the disclosure of this application. The processor may also be a combination that implements a computing function, such as a combination of one or more microprocessors, a combination of a DSP and a microprocessor, and the like.

[0201] The communication unit 1502 may be a communication interface, a transceiver, or a transceiver circuit, etc., wherein the communication interface is a general term, and in a specific implementation, the communication interface may include multiple interfaces.

[0202] The storage unit 1503 may be a memory.

[0203] When the processing unit 1501 is a processor, the communication unit 1502 is a communication interface, and the storage unit 1503 is a memory, the vehicle diagnostic device involved in the embodiment of the present application can be Fig.16 Vehicle diagnostic device 1600 is shown.

[0204] See also Fig.16 As shown, the vehicle diagnostic device 1600 includes: a processor 1601, a communication interface 1602, and a memory 1603. Optionally, the vehicle diagnostic device 1600 may also include a bus 1604. The communication interface 1602, the processor 1601, and the memory 1603 may be interconnected via the bus 1604; the bus 1604 may be a peripheral component interconnect (PCI) bus or an extended industry standard architecture (EISA) bus, etc. The bus 1604 may be divided into an address bus, a data bus, a control bus, etc. For ease of representation, Fig.16 Only one thick line is used in the diagram, but this does not mean that there is only one bus or only one type of bus.

[0205] Optionally, an embodiment of the present application further provides a computer program product carrying computer instructions, which, when executed on a computer, enables the computer to execute the method described in the above embodiment.

[0206] Optionally, an embodiment of the present application further provides a computer-readable storage medium, which stores computer instructions. When the computer instructions are executed on a computer, the computer executes the method introduced in the above embodiment.

[0207] Optionally, an embodiment of the present application also provides a chip system, including at least one processor and at least one interface circuit, the at least one interface circuit is used to perform transceiver functions and send instructions to at least one processor, when the at least one processor executes the instructions, the at least one processor executes the method described in the above embodiment.

[0208] The above is only a specific implementation of the present application, but the protection scope of the present application is not limited thereto. Any changes or substitutions within the technical scope disclosed in the present application shall be included in the protection scope of the present application. Therefore, the protection scope of the present application shall be based on the protection scope of the claims.

Claims

1. A vehicle diagnostic method, It is characterized in that Applied to a vehicle including at least one component, wherein the at least one component includes at least one domain controller, the method comprises: A first domain controller receives a diagnostic instruction from a server, the first domain controller belongs to the at least one domain controller, the diagnostic instruction is used to initiate diagnosis of a component to be diagnosed, and the component to be diagnosed is one or more of the at least one component; The first domain controller obtains the data to be diagnosed of the component to be diagnosed according to the diagnosis instruction, and the data to be diagnosed is used to diagnose the component to be diagnosed.

2. The method according to claim 1, It is characterized in that The first domain controller has a diagnostic function, and the diagnostic instruction is used to instruct the first domain controller to initiate a diagnosis of the vehicle; The first domain controller obtains the to-be-diagnosed data of the to-be-diagnosed component according to the diagnosis instruction, including: The first domain controller receives a diagnostic task from the server according to the diagnostic instruction; The first domain controller obtains the data to be diagnosed according to the diagnosis task.

3. The method according to claim 2, It is characterized in that The diagnostic task carries one or more of the identifier of the component to be diagnosed, the indicator item to be diagnosed, the diagnosis type, the identifier of the diagnostic process, and the time period of the data to be diagnosed.

4. The method according to claim 2 or 3, It is characterized in that After the first domain controller obtains the data to be diagnosed according to the diagnosis task, the method further includes: The first domain controller diagnoses the component to be diagnosed according to the diagnosis task and the data to be diagnosed; The first domain controller sends the diagnosis result to the server.

5. The method according to claim 3 or 4, It is characterized in that The diagnosis type corresponds to the diagnosis procedure represented by the identifier of the diagnosis procedure.

6. The method according to any one of claims 3 to 5, It is characterized in that The diagnosis type is used to determine whether human-computer interaction is required during the diagnosis of the component to be diagnosed.

7. The method according to any one of claims 2 to 6, It is characterized in that An intelligent diagnosis application is deployed in the first domain controller, and the intelligent diagnosis application is used to implement the diagnosis function.

8. The method according to claim 1, It is characterized in that After the first domain controller obtains the to-be-diagnosed data of the to-be-diagnosed component according to the diagnosis instruction, the method further includes: The first domain controller sends the data to be diagnosed to the server, and the data to be diagnosed is used by the server to diagnose the component to be diagnosed.

9. The method according to claim 8, It is characterized in that The first domain controller is the component to be diagnosed.

10. The method according to claim 8 or 9, It is characterized in that The diagnostic instruction carries one or more of the identifier of the component to be diagnosed, the indicator item to be diagnosed, and the time period of the data to be diagnosed.

11. The method according to any one of claims 1 to 10, It is characterized in that The first domain controller receives a diagnostic instruction from a server, including: The first domain controller receives the diagnostic instruction from the server based on the MQTT protocol.

12. The method according to any one of claims 1 to 10, It is characterized in that The first domain controller receives a diagnostic instruction from the server, including: A second domain controller receives the diagnostic instruction from the server based on the MQTT protocol, the second domain controller belongs to the at least one domain controller, and the second domain controller is different from the first domain controller; The second domain controller sends the diagnosis instruction to the first domain controller.

13. The method according to any one of claims 1 to 12, It is characterized in that The data to be diagnosed includes at least one type of CAN snapshot, log file, and fault code.

14. The method according to claim 13, It is characterized in that The log file includes a dot log, and the dot log is used to record information about fault events that occur during the operation of the software system of the component to be diagnosed; the dot log adopts a preset packaging format.

15. The method according to claim 14, It is characterized in that The preset encapsulation format includes a first field, a second field, a third field and a fourth field. The first field is used to save the identification of the component to be diagnosed, the second field is used to save the identification of the dot log, the third field is used to save the occurrence time of the fault event, and the fourth field is used to save the fault event.

16. The method according to any one of claims 1 to 15, It is characterized in that The domain controller includes: one or more of CDC, MDC, VDC, and T-BOX.

17. A vehicle diagnostic device, It is characterized in that The method comprises modules for executing each step in the method according to any one of claims 1 to 16.

18. A vehicle diagnostic device, It is characterized in that The vehicle diagnostic device comprises a processor and a memory, wherein the memory is coupled to the processor, the memory is used to store computer program code, the computer program code comprises computer instructions, and the processor reads the computer instructions from the memory so that the vehicle diagnostic device executes the method as claimed in any one of claims 1 to 16.

19. A computer-readable storage medium, It is characterized in that The computer-readable storage medium comprises a computer program, and when the computer program is executed on a vehicle diagnostic device, the vehicle diagnostic device is caused to perform the method according to any one of claims 1 to 16.

20. A computer program product, It is characterized in that The computer program product comprises: a computer program or instructions, and when the computer program or instructions are run on a computer, the computer is caused to perform the method according to any one of claims 1 to 16.

21. A vehicle, It is characterized in that The vehicle comprises a vehicle diagnostic device as claimed in claim 17 or claim 18.

Images