Vehicle diagnosis method, and apparatus

Abstract

A vehicle diagnosis method and an apparatus. The method is applied to a vehicle comprising at least one component, the at least one component comprising at least one domain controller. The method comprises: a first domain controller amongst the at least one domain controller receiving a diagnosis instruction from a server (S1001), the diagnosis instruction being used for initiating diagnosis of a component to be diagnosed, and the component to be diagnosed being one or more components amongst the at least one component comprised in the vehicle; and then, according to the diagnosis instruction, the first domain controller acquiring data to be diagnosed of the component to be diagnosed (S1002), said data being used for diagnosing the component to be diagnosed. This method can solve the problems that software faults, performance reliability and the like of domain controllers in vehicles are difficult to diagnose by means of reading fault codes, data streams, etc., thereby achieving diagnosis of domain controllers in vehicles.

Description

Vehicle diagnostic method and device

[0001] This application claims priority to the Chinese patent application filed with the State Intellectual Property Office on November 29, 2023, with application number 202311614598.9 and application name “Vehicle Diagnostic Method and Device”, the entire contents of which are incorporated by reference into this application. Technical Field

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

[0003] With the increasing popularity and development of connected technology, remote diagnosis has gradually been applied to vehicle diagnosis, improving the convenience of diagnostic operations and maintenance. Remote diagnosis refers to a method of diagnosing and repairing vehicles by simulating a diagnostic instrument through a cloud server to perform basic operations such as reading the vehicle's fault codes and data streams. Since fault codes and data streams only carry a small amount of information about hardware failures, this method can solve the problem of diagnosing hardware failures in traditional electronic control unit (ECU) components in vehicles.

[0004] With the continuous development of automotive electrical and electronic architecture, vehicles have evolved from a traditional distributed architecture centered around ECUs to a regionally centralized architecture centered around domain controllers. Compared to traditional ECUs, domain controllers are more prone to software-related failures, such as software glitches and performance reliability issues. These software-related failures are difficult to diagnose using methods such as reading fault codes and data streams.

[0005] Summary of the Invention

[0006] The present application provides a vehicle diagnostic method and device that can solve problems such as software failures and performance reliability issues 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.

[0007] To achieve the above objectives, this application adopts the following technical solutions:

[0008] 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, the method comprising: a first domain controller receiving a diagnostic instruction from a server, the first domain controller belonging to the at least one domain controller, the diagnostic instruction being used to initiate diagnosis of a component to be diagnosed, the component to be diagnosed being one or more of the at least one component; the first domain controller obtaining data to be diagnosed of the component to be diagnosed according to the diagnostic instruction, the data to be diagnosed being used to diagnose the component to be diagnosed.

[0009] Based on the above technical solution, a domain controller in a vehicle can receive diagnostic instructions from a server to initiate diagnosis of a component to be diagnosed in the vehicle. The domain controller can then obtain diagnostic data for the component based on the diagnostic instructions, and this data can be used to diagnose the component. For example, if the component to be diagnosed is a domain controller, then by obtaining data used to diagnose the domain controller, the domain controller can be diagnosed. This enables diagnosis of the domain controller in a vehicle, resolving issues such as software faults and performance reliability issues in the vehicle domain controller, which are difficult to diagnose by reading fault codes or data streams.

[0010] In one 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 this data can be used to diagnose components such as the domain controller in the vehicle. This can realize the diagnosis of the domain controller in the vehicle, and can solve problems such as 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.

[0011] In one possible design, the diagnostic task carries one or more of the following: the identifier of the component to be diagnosed, the diagnostic indicator item to be diagnosed, the diagnostic type, the identifier of the diagnostic process, and the time period in which the data to be diagnosed resides. Based on this design, the diagnostic task carries various information, such as the identifier of the component to be diagnosed, the diagnostic indicator item to be diagnosed, the diagnostic type, the identifier of the diagnostic process, and the time period in which the data to be diagnosed resides. This allows the first domain controller to determine, based on the diagnostic task, which component to diagnose, which data to obtain, and which diagnostic process to use for diagnosis. The first domain controller can then execute diagnostic operations according to the diagnostic task, enabling diagnosis of software faults, performance reliability issues, and other issues in the vehicle's domain controller.

[0012] In one possible design, after the first domain controller obtains the data to be diagnosed based on the diagnostic task, the method further includes: the first domain controller diagnosing the component to be diagnosed based on the diagnostic task and the data to be diagnosed; and the first domain controller sending the diagnostic results to the server. Based on this design, the domain controller in the vehicle diagnoses vehicle components (such as the domain controller) based on the diagnostic task and the data to be diagnosed, enabling diagnosis of software faults, performance reliability issues, and other issues in the vehicle's domain controller.

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

[0014] 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 based on the diagnosis type during the diagnosis of the component to be diagnosed. For example, if human-computer interaction is determined to be 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 human-computer interaction is determined not to be required, the first domain controller may not interact with the user, thereby avoiding disturbing the user and reducing device power consumption.

[0015] In one possible design, the first domain controller is deployed with an intelligent diagnostic application, which is used to implement the diagnostic functionality. Based on this design, by deploying the intelligent diagnostic application in the domain controller, the diagnostic functionality of the domain controller can be implemented, thereby enabling the domain controller to complete the diagnosis of components in the vehicle.

[0016] In one 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.

[0017] In one possible design, the first domain controller is the component to be diagnosed. Based on this design, when the server performs diagnostic operations, the domain controller to be diagnosed can directly send its own diagnostic data to the server, enabling diagnosis of the domain controller. This allows the vehicle-side domain controller to simply upload data, simplifying domain controller development.

[0018] In one possible design, the diagnostic instruction carries one or more of the following: the identifier of the component to be diagnosed, the indicators to be diagnosed, and the time period of the data to be diagnosed. Based on this design, when the server performs a diagnostic operation, it can directly include the identifier of the component to be diagnosed, the indicators to be diagnosed, the time period of the data to be diagnosed, etc. in the diagnostic instruction to notify the vehicle-side of which specific component and data to upload. This eliminates the need to issue a diagnostic task to notify the vehicle-side, simplifying development.

[0019] In one possible design, 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. Based on this design, the first domain controller can directly communicate with the server to receive the diagnostic instruction from the server.

[0020] In one possible design, a first domain controller receives a diagnostic instruction from a server, including: a second domain controller receiving the diagnostic instruction from the server based on the MQTT protocol, the second domain controller belonging to the at least one domain controller and different from the first domain controller; and the second domain controller sending the diagnostic instruction to the first domain controller. Based on this design, the first domain controller can also receive the server's diagnostic instruction through other domain controllers.

[0021] In one possible design, the data to be diagnosed includes at least one of CAN snapshots, log files, and fault codes. By collecting and analyzing the domain controller's data to be diagnosed, such as CAN snapshots and log files, it is possible to diagnose software faults, performance reliability issues, and other issues. For example, if a vehicle's domain controller experiences slow internet access, by collecting CAN snapshots and log files containing information such as the domain controller's network speed, network standard, and chip parameters, it can be determined that the slowdown is caused by parameter settings, allowing the specific cause of the slowdown to be diagnosed.

[0022] In one possible design, the log file includes a dot log, which records 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, the dot log specifically records fault events, and the dot log uses a unified format, which enables rapid analysis of the dot log, allowing for more efficient diagnosis and improving diagnostic efficiency.

[0023] 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 stores the identifier of the component to be diagnosed, the second field stores the identifier of the dot log, the third field stores the time of occurrence of the fault event, and the fourth field stores the fault event. Thus, the preset encapsulation format uses a JSON structure, making it easier for maintenance personnel to understand and analyze the data to be diagnosed during vehicle diagnosis.

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

[0025] In a second aspect, a vehicle diagnostic method is provided, which is applied to a server. The method includes: the server generates a diagnostic instruction, the diagnostic instruction is used to initiate a diagnosis of a component to be diagnosed contained in a vehicle, 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, the at least one component contains at least one domain controller, and the first domain controller belongs to the at least one domain controller.

[0026] 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.

[0027] In one 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.

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

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

[0030] 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.

[0031] 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.

[0032] 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.

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

[0034] In one 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 of the data to be diagnosed.

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

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

[0037] 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 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.

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

[0039] In a third aspect, a vehicle diagnostic device is provided, which has the function of implementing the method described in any one of the designs in the first or second aspect above. The function can be implemented by hardware, or it can be implemented 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 operations in the method described in any one of the designs in the first or second aspect above. The processing unit is used to perform the processing operations in the method described in any one of the designs in the first or second aspect above.

[0040] 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 comprising computer instructions, and the processor reads the computer instructions from the memory so that the vehicle diagnostic device executes the method described in any one of the designs of the first or second aspects above.

[0041] In one possible design, the vehicle diagnostic device further includes a communication interface that can be used to communicate between the vehicle diagnostic device and 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 related circuits.

[0042] In one possible design, the vehicle diagnostic device further 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.

[0043] 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 the method described in any one of the designs of the first aspect or the second aspect above.

[0044] In a sixth aspect, a computer program product is provided, comprising: a computer program or instructions, which, when executed on a computer, causes the computer to execute the method described in any one of the first or second aspects above.

[0045] 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. 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 or second aspect above.

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

[0047] 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

[0048] FIG1 is a schematic diagram of the architecture of a communication system provided in an embodiment of the present application;

[0049] FIG2 is a schematic structural diagram of a first device and a second device provided in an embodiment of the present application;

[0050] FIG3 is a schematic structural diagram of another first device and a second device provided in an embodiment of the present application;

[0051] FIG4 is a schematic structural diagram of another first device and a second device provided in an embodiment of the present application;

[0052] FIG5 is a schematic structural diagram of another first device and a second device provided in an embodiment of the present application;

[0053] FIG6 is a schematic structural diagram of another first device and a second device provided in an embodiment of the present application;

[0054] FIG7 is a schematic structural diagram of another first device and a second device provided in an embodiment of the present application;

[0055] FIG8 is a schematic structural diagram of another first device and a second device provided in an embodiment of the present application;

[0056] FIG9 is a schematic diagram of the structure of an intelligent diagnostic application provided in an embodiment of the present application;

[0057] FIG10 is a flow chart of a vehicle diagnostic method according to an embodiment of the present application;

[0058] FIG11 is a schematic diagram of a mobile phone interface provided in an embodiment of the present application;

[0059] FIG12 is a schematic diagram of the structure of a dot log provided in an embodiment of the present application;

[0060] FIG13 is a flow chart of another vehicle diagnostic method provided in an embodiment of the present application;

[0061] FIG14 is a flow chart of another vehicle diagnostic method provided in an embodiment of the present application;

[0062] FIG15 is a schematic structural diagram of a vehicle diagnostic device provided in an embodiment of the present application;

[0063] FIG16 is a schematic structural diagram of another vehicle diagnostic device provided in an embodiment of the present application. DETAILED DESCRIPTION

[0064] To facilitate the clear description of the technical solutions of the embodiments of the present application, in the embodiments of the present application, the words "first" and "second" are used to distinguish between identical or similar items with substantially the same functions and effects. Those skilled in the art will understand that the words "first" and "second" do not limit the quantity or execution order, and the words "first" and "second" do not necessarily mean different.

[0065] 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.

[0066] 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 be connected to the vehicle's on-board diagnostics (OBD) system through the vehicle communications interface (VCI), and provides various functions such as reading diagnostic trouble codes (DTCs), reading vehicle version information, reading data identifiers (DIDs) of data streams, clearing fault codes, and flashing software to achieve daily diagnosis and maintenance of vehicles. Among them, by reading DTCs, the fault codes and maintenance suggestions of the problem components 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.

[0067] With the increasing popularity and development of connected technology, remote diagnosis is gradually being applied to vehicle diagnostics to improve the convenience of diagnosis and maintenance. Remote diagnosis refers to the use of cloud servers to simulate diagnostic instruments, performing basic operations such as remotely reading vehicle information, reading vehicle fault codes, reading freeze frames, clearing fault codes, reading component fault codes, and reading component data streams to achieve vehicle diagnosis and maintenance.

[0068] At present, the remote diagnosis provided by cloud servers and the diagnostic methods provided by diagnostic instruments are both based on the unified diagnostic services (UDS) diagnostic capabilities 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 a diagnostic database used by standard diagnostic instruments developed by the Association for Standardization 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.

[0069] In the above diagnostic method, the fault codes and data streams read only carry a small amount of information when a hardware fault occurs. Therefore, 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 (DCUs). 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 components such as the engine, brakes, and doors respectively. Each ECU can be connected together to communicate through a controller area network (CAN) bus or a local interconnect network (LIN) bus.

[0070] As the use of electronic and electrical products in vehicles increases, the number of ECUs is gradually increasing. To reduce vehicle costs, a regionally centralized architecture centered around domain controllers has emerged. Domain controllers can divide vehicle functions into several domains, such as the powertrain domain and the body electronics domain. They then utilize powerful multi-core central processing units (CPUs) or graphics processing units (GPUs) to centrally control functions previously assigned to individual ECUs within a relatively centralized control domain. Domain controllers are no longer simple single-chip microcomputers or embedded systems; they are now highly intelligent high-performance computers (HPCs) that run complex operating systems and application software to enable high-computing applications such as network connectivity, smart cockpits, intelligent vehicle control, and intelligent driving.

[0071] In a distributed architecture centered around a domain controller, domain controller failures primarily include hardware failures, software failures, and performance and reliability issues. Domain controller hardware failures can be diagnosed using the aforementioned diagnostic methods, but software failures and performance and reliability issues are more difficult to diagnose using methods such as reading fault codes and data streams. For example, if a vehicle's domain controller experiences slow internet access, and if the domain controller hardware is healthy, reading fault codes and data streams will only confirm that the hardware is healthy and will not diagnose the cause of the slow internet access.

[0072] 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 through a pre-installed intelligent diagnostic application, and solves problems such as software failures and performance reliability issues of the domain controller that are difficult to diagnose by reading fault codes, data streams, etc.

[0073] 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.

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

[0075] Among them, the first device 101 is the diagnosed device. Exemplarily, the first device 101 can be various devices such as vehicles, artificial intelligence (AI) devices (such as but not limited to robots, mechanical dogs, etc.), drones, etc. In Figure 1, the first device 101 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.

[0076] The CDC is a domain controller used to control the smart cockpit domain. The smart cockpit domain integrates various information, including driving and entertainment information, based on the human-machine interaction scenario in the cockpit. For example, the smart cockpit domain includes, but is not limited to, the head-up display (HUD), instrument panel (cockpit), and in-vehicle infotainment (IVI). The VDC is a domain controller used to control the vehicle domain (also known as the body domain) and chassis domain. The vehicle domain primarily integrates body electronics components, such as, but not limited to, lights, wipers, and central door locks. The chassis domain integrates driving-related functions, such as, but not limited to, the transmission, driving system, steering system, and braking system. The MDC is a domain controller used to control the autonomous driving domain. The autonomous driving domain integrates functions related to autonomous driving, such as, but not limited to, environmental perception, positioning, path planning, and decision-making control. The T-BOX is a domain controller used to control remote monitoring and operation of devices. The T-BOX acts as a wireless gateway, providing a remote communication interface for devices and offering 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.

[0077] 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.

[0078] The second device 102 can initiate a remote diagnosis of the first device 101. For example, the second device 102 can be a server, which can be a device or server with computing capabilities, such as a cloud server or a network server. The server can be a single server, a server cluster consisting of multiple servers, or a cloud computing service center.

[0079] In some embodiments, the communication system 100 shown in Figure 1 may further 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 using a display screen, speaker broadcast, etc.) the diagnostic results of the first device x so that the user can know the diagnostic results. Exemplarily, the third device 103 can be various devices such as mobile phones, tablet computers, wearable devices, AI devices, and vehicle-mounted devices. Figure 1 shows that the third device 103 is a mobile phone.

[0080] Optionally, the first device 101 and the second device 102, and / or the second device 102 and the third device 103 can communicate via a wired communication technology or a 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), world-wide interoperability for microwave access (WiMAX) communication technology, fifth generation (5G) communication technology (e.g., new radio (NR) technology), and future mobile communication technologies, such as sixth generation (6G) mobile communication technology.

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

[0082] It can be understood that the intelligent diagnostic application in the embodiments of the present application can be an application program, a software module, a chip, a component, etc.

[0083] 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 diagnosis of the domain controller in which 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 diagnosis of other domain controllers or traditional ECUs other than the domain controller in which it is located, and the embodiments of the present application do not impose specific restrictions on this.

[0084] 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 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 controller A and domain controller B. The intelligent diagnostic application deployed on domain controller A can be used to implement diagnosis of domain controller A and domain controller C, and the intelligent diagnostic application deployed on domain controller B can be used to implement diagnosis of domain controller B and domain controller D. Alternatively, the intelligent diagnostic application deployed on domain controller A can be used to diagnose domain controller C and domain controller D, and the intelligent diagnostic application deployed on domain controller B can be used to diagnose domain controller A and domain controller B. The embodiments of the present application do not impose specific restrictions on which intelligent diagnostic application is specifically used to diagnose which domain controllers, traditional ECUs, etc.

[0085] In other embodiments, the smart diagnostic application can be deployed on a domain controller included in first device 101. Specifically, first device 101 can deploy only one smart diagnostic application, which can be used to diagnose all domain controllers, traditional ECUs, and other components included in first device 101. This reduces the complexity of deploying the smart diagnostic application. In one specific implementation, the smart diagnostic application can be deployed on a smart cockpit. Because smart cockpits have superior computing power, extensive storage, and user interaction, deploying the smart diagnostic application on a smart cockpit can reduce development complexity.

[0086] In this embodiment, FIG2 shows a schematic structural diagram of a first device 101 and a second device 102 provided in an embodiment of the present application.

[0087] As shown in FIG2 , at least one domain controller is deployed in the first device 101 , such as domain controller 1 , domain controller 2 , etc. (only two are shown in FIG2 ).

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

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

[0090] Optionally, the connection established above may be a connection established based on the 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.

[0091] 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.

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

[0093] Among them, the remote diagnostic service can be used to initiate diagnosis of the first device 101, such as including but not limited to diagnosis of various components such as the domain controller and traditional ECU contained in the first device 101. In some embodiments, the remote diagnostic service can initiate diagnosis of the first device 101 regularly or periodically. In other embodiments, the remote diagnostic service can initiate diagnosis of the first device 101 based on the operation of the operation and maintenance personnel, or the instructions of the third device 103 shown in Figure 1. The embodiment of the present application does not specifically limit the timing of initiating diagnosis of the first device 101 by the remote service.

[0094] In some embodiments, the remote diagnostic service may be used to generate one or more 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 .

[0095] The communication module 2 may be configured 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 configured to receive one or more of a diagnostic result, data to be diagnosed, etc. from the first device 101 and send the one or more of the diagnostic result, data to be diagnosed, etc. to the remote diagnostic service.

[0096] It is understood that Figure 2 uses an example in which 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. In this way, the diagnostic instruction does not need to be transmitted between different domain controllers, which can reduce signaling overhead.

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

[0098] In some embodiments, the domain controller in the first device 101 can receive diagnostic instructions from the second device 102 using the Message Queuing Telemetry Transport (MQTT) protocol. The MQTT protocol is a publish-and-subscribe communication protocol whose system architecture includes an MQTT client and an MQTT server. An MQTT message contains two parts: a topic and a preload. An MQTT client can register or listen to a corresponding topic on the MQTT server.

[0099] 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.

[0100] 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.

[0101] In this embodiment, in combination with the structure shown in FIG2 , FIG4 shows a schematic structural diagram of another first device 101 and a second device 102 provided in an embodiment of the present application.

[0102] As shown in FIG4 , the communication module 1 included in the first device 101 shown in FIG2 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.

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

[0104] In some embodiments, the protocol used by the domain controller may differ from the MQTT protocol. For example, the domain controller may communicate using the Scalable Service-Oriented Middleware over IP (SOMEIP) protocol. Therefore, as shown in FIG4 , an MQTT message broker may also be deployed on the domain controller 1. The MQTT message broker may be used to convert MQTT messages into the message format specified by the protocol used by the domain controller, such as SOMEIP messages or messages in other formats. The MQTT message broker may also send the converted diagnostic instructions to the intelligent diagnostic application.

[0105] In some embodiments, as shown in FIG4 , the first device 101 may also be deployed with one or more legacy ECUs and a unified diagnostic services (UDS) agent. The intelligent diagnostic application can also diagnose these legacy ECUs. For example, after receiving a diagnostic task, if the intelligent diagnostic application determines that a legacy ECU needs to be diagnosed based on the task, the intelligent diagnostic application can read the fault code of the legacy ECU through the UDS agent and diagnose the legacy ECU based on the fault code.

[0106] For the introduction of other modules shown in FIG4 , please refer to the introduction of the corresponding modules shown in FIG2 .

[0107] It is understood that the structure shown in FIG4 is taken as an example in combination with the structure shown in FIG2. Similarly, FIG5 shows a schematic structural diagram of another first device 101 and a second device 102 provided in an embodiment of the present application in combination with the structure shown in FIG3. As shown in FIG5, the communication module 1 such as that shown in FIG3 can include an MQTT client module, which can 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. For the introduction of other modules shown in FIG5, please refer to the introduction of the corresponding modules shown in FIG3 and FIG4.

[0108] It will be appreciated that the above embodiments all utilize the first device 101 having a diagnostic function to perform diagnostic operations. In other embodiments, the second device 102 may have a diagnostic function that can be used to diagnose one or more controllers, traditional ECUs, etc. included in the first device 101. In other words, the second device 102 may perform diagnostic operations on the domain controller included in the first device 101. Optionally, this diagnostic function may also be implemented through an intelligent diagnostic application deployed in the second device 102.

[0109] In this embodiment, FIG6 shows a schematic structural diagram of another first device 101 and a second device 102 provided in an embodiment of the present application.

[0110] As shown in FIG6 , at least one domain controller is deployed in the first device 101 , such as domain controller 1 , domain controller 2 , etc. (only two are shown in FIG6 ).

[0111] Domain controller 1 is deployed with a communication module 1, which can be used to interact with second device 102 and receive diagnostic instructions from second device 102. The diagnostic instructions can be used to instruct the initiation of diagnosis of the domain controller to be diagnosed. Furthermore, communication module 1 can send the received diagnostic instructions to the domain controller to be diagnosed, so that the domain controller to be diagnosed can send its own diagnostic data to second device 102 according to the diagnostic instructions.

[0112] For example, domain controller 2 is the domain controller to be diagnosed. Domain controller 2 is deployed with a data acquisition module. Based on the diagnostic instructions from communication module 1, domain controller 2 can use the data acquisition module to collect its own data to be diagnosed. Furthermore, domain controller 2 can upload this data to second device 102, allowing second device 102 to diagnose domain controller 2 based on the data to be diagnosed.

[0113] 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 through software, hardware, or a combination of software and hardware.

[0114] Optionally, in this embodiment, a data collection module may be deployed on each domain controller included in the first device 101, so that after receiving a diagnostic instruction, each domain controller can use the data collection module to collect its own data to be diagnosed based on the diagnostic instruction to perform its own diagnosis. Alternatively, the data collection module may be deployed on only one or some of the domain controllers, and the data collection 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.

[0115] 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 the data acquisition module in other domain controllers other than 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.

[0116] 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 diagnostic data of the domain controller to be diagnosed from the first device 101, diagnose the domain controller to be diagnosed based on the diagnostic data, and obtain a diagnostic result.

[0117] For the introduction of other modules shown in FIG6 , please refer to the corresponding introduction of the modules shown in FIG2 .

[0118] Similarly, similar to the structure shown in FIG3 , in the structure shown in FIG6 , the communication module 1 can also be deployed on the domain controller 2 . Furthermore, similar to the structures shown in FIG4 and FIG5 , the structure shown in FIG6 can also be presented in forms such as those shown in FIG7 and FIG8 . Specifically, in the structures shown in FIG7 and FIG8 , when the second device 102 is diagnosing a traditional ECU, the second device 102 can send a diagnostic instruction to the UDS agent. Accordingly, 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.

[0119] It is understood that the structures shown in Figures 7 and 8 are based on the example of deploying the MQTT client module and the UDS agent on the same domain controller. In other embodiments, the MQTT client module and the UDS agent can also be deployed on different domain controllers. The embodiments of the present application do not limit the location of the UDS deployment. 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.

[0120] For the introduction of each module shown in Figures 7 and 8, please refer to the introduction of the corresponding modules in Figures 4, 5, 6, etc.

[0121] Optionally, in the above embodiment, when the intelligent diagnostic application is deployed on the second device 102, the second device 102 does not need to issue a diagnostic task to the first device 101, and can directly carry the content of the diagnostic task in the diagnostic instruction. This can simplify the development of the first device 101. Of course, the second device 102 can also diagnose the first device 101 by issuing diagnostic instructions and diagnostic tasks, and this embodiment of the application is not limited to this.

[0122] It is understood that the embodiments of the present application do 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 a domain controller other than the T-BOX. The structures shown in Figures 2 to 8 are based on the example of deploying only one communication module 1 on the first device 101. The embodiments of the present application do not impose any specific restrictions on the number of communication modules 1, and they can also be deployed on multiple domain controllers included in the first device 101.

[0123] For example, taking the deployment of the intelligent diagnosis application in the first device 101 as an example, FIG9 shows a structural diagram of an intelligent diagnosis application provided in an embodiment of the present application.

[0124] As shown in FIG9 , the intelligent diagnosis application includes a communication module 3 , a diagnosis database, a diagnosis process executor, and a data analysis module.

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

[0126] The diagnostic database may be used to store diagnostic processes from the second device 102. The diagnostic processes stored in the diagnostic database may be synchronized with the diagnostic processes in the second device 102. Optionally, the diagnostic processes 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 embodiments of the present application do not impose any specific restrictions on the timing of obtaining the diagnostic processes from the second device 102.

[0127] 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.

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

[0129] In some embodiments, the intelligent diagnosis application shown in FIG9 may further include a human-computer interaction module. If human-computer interaction is required during the diagnosis process, the human-computer interaction module may provide a human-computer interaction interface (e.g., 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 based on the user's operation results.

[0130] Optionally, when the intelligent diagnostic application is deployed on the second device 102, the intelligent diagnostic application may include more or fewer modules than those shown in FIG9 . For example, it may not include a human-computer interaction module or a command interaction module. The functions of each module may differ. For example, when the intelligent diagnostic application is deployed on the second device 102, the communication module 3 may be used to send at least one of a diagnostic instruction and a diagnostic task to the first device 101. It may also be used to receive at least one of a diagnostic result and data to be diagnosed from the first device 101.

[0131] It can be understood that the structures shown in Figures 2 to 9 are obtained based on functional division, and there may be other division methods in actual application. For example, the intelligent diagnostic application and remote diagnostic service contained in the second device 102 can also be divided into a functional module.

[0132] In the following example, the first device 101 is a vehicle, the second device 102 is a server, and the third device 103 is a mobile phone. FIG10 shows a flow chart of a vehicle diagnostic method provided by an embodiment of the present application. As shown in FIG10 , the method includes the following steps:

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

[0134] Among them, the first domain controller can be one or more domain controllers included in the vehicle, and the vehicle can include at least one component, and this 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. 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, this at least one component may also include at least one traditional ECU.

[0135] The diagnostic instruction may be used to initiate diagnosis of a component to be diagnosed, which 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.

[0136] 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.

[0137] In other embodiments, the second domain controller may function as an MQTT client, receive diagnostic instructions from the server based on the MQTT client, and send the received diagnostic instructions 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 different domain controller from the first domain controller.

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

[0139] In some embodiments, the server may execute step S1001 and subsequent steps based on 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 based on the vehicle's VIN and send a diagnostic instruction to the vehicle based on the IP address. Accordingly, the vehicle may receive the diagnostic instruction through the first domain controller.

[0140] In other embodiments, the server may receive a user instruction from a mobile phone. In response to the user instruction, the server may execute step S1001 and subsequent steps. For example, a mobile phone may have an application installed that triggers vehicle diagnostics, and the user may use the application to trigger vehicle diagnostics. For example, FIG11 shows a schematic diagram of a mobile phone interface provided in an embodiment of the present application.

[0141] As shown in (1) of FIG11 , the mobile phone may display an application interface 1100, which may include buttons (or controls, 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.

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

[0143] Optionally, during the vehicle diagnosis process, the mobile phone may also present an application interface 1110 such as that shown in (2) in FIG11 , so that the user can confirm the progress of the vehicle diagnosis (e.g., the current progress is 70%, and it is expected to be completed in 3 minutes), precautions (e.g., during vehicle diagnosis, please keep the vehicle still, power on and shift to P gear), etc. The application interface 1110 may also include one or more of a background execution button 1111 and a cancel button 1112. The background execution button 1111 may 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 may be used to cancel the vehicle diagnosis.

[0144] In some other embodiments, the server may also periodically or regularly initiate vehicle diagnosis, and then execute step S1001 and subsequent steps based on its own initiation operation. It is understood that the embodiments of the present application do not impose any restrictions on the timing of the server initiating vehicle diagnosis.

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

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

[0147] In some embodiments, the data to be diagnosed may include at least one type of controller area network (CAN) snapshots, log files, and fault codes. Optionally, when the component to be diagnosed is a domain controller, the data to be diagnosed may include at least one type of CAN snapshots and log files. 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, it is possible to diagnose software failures, performance reliability issues, etc. of the domain controller. For example: If the domain controller of a vehicle has a problem of slow Internet access, by collecting CAN snapshots, log files, etc. 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.

[0148] When the component to be diagnosed is a traditional ECU, the diagnostic data can include fault codes. This allows for diagnosis of hardware faults in traditional ECUs. Furthermore, different types of diagnostic data can be obtained for different types of components, enabling diagnosis of these different types of components.

[0149] CAN snapshots can be generated based on the collected CAN data. This saves vehicle communication bandwidth and signaling overhead by uploading the generated CAN snapshots to the server instead of uploading the original CAN data.

[0150] 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 flow of information (or flow log) of the software system's operating events of the component to be diagnosed, while 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. This information can be used to characterize the record at the time of the fault, the status of the component to be diagnosed, etc. Optionally, since traditional ECUs do not have log files, domain controllers do. Therefore, the components to be diagnosed described in the log introduction section may all refer to the domain controller to be diagnosed, and are described uniformly here.

[0151] 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. Optionally, a scenario-type fault may include one or more different fault events, 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.

[0152] In some embodiments, the logging logs can be formatted in a pre-set format. This allows for a unified format for all logs recording fault events of components to be diagnosed. This allows for rapid identification of various data, including whether a fault has occurred, its frequency, and key information at the time of occurrence. This facilitates analysis of vehicle faults and improves diagnostic efficiency.

[0153] Exemplarily, Figure 12 shows a structural diagram of a preset encapsulation format provided by an embodiment of the present application. As shown in Figure 12, 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 dotting log, and optionally, the identification of the dotting log can be globally unique. The third field can be used to save the occurrence time of the fault event recorded in the dotting 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.

[0154] Based on the above technical solution, a vehicle's domain controller can receive diagnostic instructions from a server to initiate a diagnosis of a component in the vehicle. The domain controller can then obtain diagnostic data for the component based on the diagnostic instructions, which can be used to diagnose the component. If the component to be diagnosed is the domain controller to be diagnosed, this enables diagnosis of the vehicle's domain controller, resolving issues such as software faults and performance reliability issues in the vehicle's domain controller that are difficult to diagnose simply by reading fault codes or data streams.

[0155] In some embodiments, the first domain controller has diagnostic functionality, and the diagnostic instruction may specifically instruct the first domain controller to initiate vehicle diagnostics. Optionally, the diagnostic functionality of the first domain controller may be implemented via an intelligent diagnostic application deployed in the first domain controller. For an introduction to this intelligent diagnostic application, please refer to the above description. In this embodiment, step S1002 shown in Figure 10 may be specifically implemented as steps S1003 to S1004 shown in Figure 13.

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

[0157] For the specific implementation of receiving the diagnostic task according to the diagnostic instruction, please refer to the relevant implementation shown in Figure 2.

[0158] 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 to obtain, which diagnostic process to adopt for diagnosis, and the like.

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

[0160] Optionally, in this embodiment, the diagnostic task carries one or more of an identifier of the component to be diagnosed, an indicator to be diagnosed, a diagnostic type, an identifier of the diagnostic process, and a time period in which the data to be diagnosed is located. The first domain controller may obtain the data to be diagnosed based on one or more of the identifier of the component to be diagnosed, the indicator to be diagnosed, and the time period in which the data to be diagnosed is located, etc., carried in the diagnostic task.

[0161] 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 diagnostic indicator item to be diagnosed, the diagnosis type, the identifier of the diagnostic process, and the time period of the data to be diagnosed.

[0162] 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.

[0163] 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 central control screen as the human-computer interaction interface, 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.

[0164] 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.

[0165] The identifier of the diagnostic process can be used by the first domain controller to determine whether to perform a diagnosis based on various diagnostic processes. In some examples, the first domain controller can search for a corresponding diagnostic process from a diagnostic database such as that shown in FIG. 9 based on the received identifier of the diagnostic process. If a corresponding diagnostic process is found, subsequent diagnostic operations are performed based on the found diagnostic process. If a corresponding diagnostic process is not found, the first domain controller can obtain a corresponding diagnostic process from a server based on the received identifier of the diagnostic process, and then perform subsequent diagnostic operations based on the obtained diagnostic process.

[0166] 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.

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

[0168] 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 components to be diagnosed can be diagnosed based only on the diagnostic process.

[0169] In this embodiment, the diagnostic type and the diagnostic process represented by the identifier of the diagnostic process may correspond to each other. 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.

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

[0171] In some embodiments, after the first domain controller executes step S1004, the method shown in FIG13 may further include steps S1005 to S1006.

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

[0173] 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.

[0174] In some embodiments, the first domain controller can 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 can 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-type 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-type faults. Of course, under this embodiment, the vehicle can also choose to upload the dot log to the server for analysis, and the embodiment of the present application does not limit this.

[0175] Taking the system log as an example, the first domain controller can upload the system log to the server, which will then analyze the system log based on the diagnostic process. Since system logs are running logs with inconsistent formats and data parsing, it is difficult for vehicles to analyze them. Instead, the system logs can be uploaded to the server for search and analysis by maintenance personnel. Optionally, when the diagnostic type is log-based fault diagnosis, the obtained log file is the system log, which allows for the diagnosis of log-based faults.

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

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

[0178] 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, which can be used to diagnose the component to be diagnosed based on the data to be diagnosed.

[0179] For the introduction of other steps shown in FIG13 , please refer to the introduction of the corresponding steps in FIG10 .

[0180] In this embodiment, the diagnostic instruction described in step S1001 can directly carry the content of the diagnostic task. For example, the diagnostic instruction can 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 an introduction to these parameters, please refer to the above. Of course, the aforementioned diagnostic instruction can also directly carry a diagnostic identifier. Accordingly, after receiving the diagnostic identifier, the vehicle can determine which component and which data to upload.

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

[0182] Table 1

[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, the steps shown in FIG. 10 may further include steps S1007 to S1008 shown in FIG. 14 .

[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 based on the diagnostic flow, diagnostic type, etc., and use the diagnostic process to analyze the data to be diagnosed to diagnose the component to be diagnosed.

[0189] For the introduction of other steps shown in FIG14 , please refer to the introduction of the corresponding steps in FIG10 .

[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 diagnosis of the vehicle 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. For example, Figure 10 shows a schematic diagram of an interface for outputting diagnosis results of a mobile phone provided in an embodiment of the present application. As shown in (3) in Figure 11, the mobile phone can display the diagnosis result 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-mentioned 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] FIG15 is a schematic diagram of the structure 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. For example, the vehicle diagnostic device 1500 may include: a processing unit 1501 and a communication unit 1502.

[0195] As a possible example, taking the vehicle diagnostic device 1500 as a vehicle, or a module (such as a chip) used in a vehicle, as an example, the processing unit 1501 is used to support the vehicle diagnostic device 1500 in performing the processing functions performed by the vehicle as shown in any one of Figures 1 to 14. The communication unit 1502 is used to support the vehicle diagnostic device 1500 in performing the communication functions performed by the vehicle as shown in any one of Figures 1 to 14.

[0196] As another possible example, taking the vehicle diagnostic device 1500 as a server, or a module (e.g., a chip) used in a server, as an example, the processing unit 1501 is configured to support the vehicle diagnostic device 1500 in performing the processing functions performed by the server as shown in any one of Figures 1 to 14. The communication unit 1502 is configured to support the vehicle diagnostic device 1500 in performing the communication functions performed by the server as shown in any one of Figures 1 to 14.

[0197] Optionally, the vehicle diagnostic device 1500 shown in FIG15 may further include a storage unit 1503 storing a program or instruction. When the processing unit 1501 executes the program or instruction, the vehicle diagnostic device 1500 shown in FIG15 may execute the method described in the above method embodiment.

[0198] Optionally, the vehicle diagnostic device 1500 shown in FIG15 may further include an input-output unit (not shown in the figure), which may be used to provide a human-computer interaction interface to implement human-computer interaction.

[0199] The technical effects of the vehicle diagnostic device 1500 shown in FIG15 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 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 device, a transistor logic device, a hardware component, or any combination thereof. It may implement or execute the various exemplary logic blocks, modules, and circuits described in conjunction with the disclosure of this application. A processor may also be a combination that implements computing functions, 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. 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 may be the vehicle diagnostic device 1600 shown in FIG. 16 .

[0204] Referring to FIG. 16 , the vehicle diagnostic device 1600 includes: a processor 1601, a communication interface 1602, and a memory 1603. Optionally, the vehicle diagnostic device 1600 may further 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 shows only one thick line, but this does not mean that there is only one bus or 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 embodiment of the present application, but the scope of protection 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 scope of protection of the present application. Therefore, the scope of protection of the present application shall be based on the scope of protection of the claims.

Claims

1. A vehicle diagnostic method, 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, 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, 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, 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, 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, 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, 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, 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, characterized in that The first domain controller is the component to be diagnosed.

10. The method according to claim 8 or 9, 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, 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, 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, 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, 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, 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, characterized in that The domain controller includes: one or more of CDC, MDC, VDC, and T-BOX.

17. A vehicle diagnostic device, 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, 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, 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, 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, characterized in that: The vehicle comprises a vehicle diagnostic device as claimed in claim 17 or claim 18.

Images