Vehicle communication fault identification method and related device

Abstract

The invention relates to the technical field of vehicles, and particularly discloses a vehicle communication fault identification method, device and equipment, a controller, a system and a medium, which are used for improving the identification efficiency of a vehicle communication fault. The method comprises the steps that a controller system log fed back by each controller participating in target network communication in a vehicle is received, and the controller system log comprises communication state record data of the corresponding controller; the communication state record data comprises communication state information and corresponding time point information of various communication detection types of different hierarchies of the target network, and the communication state information comprises an abnormal mark during abnormal detection; querying all associated communication state record data of the communication fault problem from the received communication state record data of the controller system log; and analyzing the associated communication state record data of each level in all the associated communication state record data layer by layer until the fault reason of the communication fault problem is identified.

Description

Technical Field

[0001] This application relates to the field of automotive technology, and in particular to a method, apparatus, device, controller, system and medium for identifying vehicle communication faults. Background Technology

[0002] Vehicle communication failures are a type of aftermarket issue. For example, Ethernet communication failures manifest as abnormal communication. Once a failure occurs, it affects the function of transmitting data via Ethernet (such as intelligent driving cloud data, over-the-air upgrades, etc.), causing these functions to be unusable or downgraded, leading to user dissatisfaction and complaints.

[0003] In traditional solutions, the user is typically invited to bring their vehicle to the service center based on their description of the problem. Personnel are then arranged to conduct on-site testing and collect data to analyze the vehicle's Ethernet communication failure. Alternatively, an Ethernet communication system bench is set up to attempt to reproduce the problem based on the user's description, and bench testing is conducted to collect and analyze the vehicle's Ethernet communication failure.

[0004] However, in the above processing methods, the root cause of the problem may be sporadic. If it cannot be reproduced, the processing time will be uncertain, resulting in low fault identification efficiency. Summary of the Invention

[0005] This application provides a vehicle communication fault identification method, apparatus, device, controller, system, and medium to improve the identification efficiency of vehicle communication faults, thereby solving the technical problem of low communication fault identification efficiency in traditional solutions.

[0006] Firstly, a method for identifying vehicle communication faults is provided, including:

[0007] The system receives controller system logs from each controller participating in the target network communication in the vehicle. The controller system logs record the communication status data of the corresponding controller. The communication status data includes communication status information and corresponding time point information for various communication detection types at different levels of the target network. The communication status information includes anomaly markers when anomalies are detected.

[0008] Based on the mapping relationship between the communication failure problem and the target network communication, all associated communication status record data of the communication failure problem are retrieved from the communication status record data of the received controller system log.

[0009] According to the hierarchical order of the target network, the associated communication status record data of each level in all associated communication status record data is analyzed layer by layer until the cause of the communication failure is identified.

[0010] Furthermore, the communication status recording data includes the controller's record data at the following levels under target network communication:

[0011] Communication status recording data of one or more communication detection types at the physical layer;

[0012] Communication status recording data of one or more communication detection types at the data link layer;

[0013] Communication status recording data for one or more communication detection types in the system kernel / communication protocol stack;

[0014] Communication status recording data of one or more communication detection types in communication middleware.

[0015] Furthermore, the hierarchical order is as follows: physical layer, data link layer, system kernel / communication protocol stack, and communication middleware.

[0016] Further, the step of retrieving all associated communication status records of the communication failure from the received communication status record data of the controller system log, based on the mapping relationship between the communication failure and the target network communication, includes:

[0017] Based on the mapping relationship between the communication failure and the target network communication, and the time period of the communication failure, all associated communication status records of the communication failure are retrieved from the communication status record data received from the controller system log.

[0018] Furthermore, after analyzing the associated communication status record data of each level in all associated communication status record data according to the hierarchical relationship of different levels of the target network to identify the cause of the communication failure, the method further includes:

[0019] A graphical display is provided, wherein the graphical display interface displays communication anomaly record data corresponding to the communication failure problem, and the communication anomaly record data is marked in the form of preset tags.

[0020] Furthermore, the communication status recording data for various communication detection types includes corresponding detection preconditions and log recording conditions.

[0021] Furthermore, the communication status record data of the controller is stored in the controller system log in a preset standard format.

[0022] Secondly, a method for identifying vehicle communication faults is provided, including:

[0023] The detection method detects the communication status of various communication detection types according to different layers of the target network, so as to obtain the communication status record data of the controller. The communication status record data includes communication status information of various communication detection types and corresponding time point information. The communication status information includes anomaly markers when an anomaly is detected.

[0024] The communication status record data is written to the corresponding controller system log file;

[0025] When a log retrieval instruction is received from a cloud or local tool, the controller system log file is sent to the cloud or local tool. This allows the cloud or local tool to query all associated communication status records of the communication failure from the received controller system log communication status record data, based on the mapping relationship between the communication failure and the target network communication. Then, following the hierarchical order of different levels of the target network communication, the tool analyzes the associated communication status record data at each level of all associated communication status records until the cause of the communication failure is identified.

[0026] Furthermore, the method also includes:

[0027] When an update request is received, the detection method is updated according to the update data, which includes one or more of the following: detection logic, communication detection type, or detection parameters.

[0028] Furthermore, the communication status recording data includes the controller's recording data at the following levels of the target network:

[0029] Communication status recording data of one or more communication detection types at the physical layer;

[0030] Communication status recording data of one or more communication detection types at the data link layer;

[0031] Communication status recording data for one or more communication detection types in the system kernel / communication protocol stack;

[0032] Communication status recording data of one or more communication detection types in communication middleware.

[0033] Furthermore, the communication status recording data for various communication detection types is obtained based on the detection preconditions and log recording conditions corresponding to the communication detection type.

[0034] Thirdly, a vehicle communication fault identification device is provided for cloud-based applications, the device comprising:

[0035] The first sending module is used to send log recall instructions to the vehicle;

[0036] The first receiving module is used to receive the controller system logs fed back by each controller participating in the target network communication in the vehicle in response to the log recall instruction. The controller system log records include the controller's communication status record data. The communication status record data includes communication status information and corresponding time point information for various communication detection types at different levels of the target network. The communication status information includes anomaly markers when anomalies are detected.

[0037] The first processing module is used to query all associated communication status record data of the communication failure problem from the communication status record data of the received controller system log according to the mapping relationship between the communication failure problem and the target network communication; and to analyze the associated communication status record data of each level of all associated communication status record data layer by layer according to the hierarchical order relationship of the different levels of the target network communication until the cause of the communication failure problem is identified.

[0038] Fourthly, a vehicle communication fault identification device is provided for a controller, the device comprising:

[0039] The second processing module is used to detect the communication status of various communication detection types according to the detection methods of different communication detection types under different layers of the target network, so as to obtain the communication status record data of the controller. The communication status record data includes the communication status information of various communication detection types and the corresponding time point information; and writes the communication status record data into the corresponding controller system log file. The communication status information includes the exception marker when an exception is detected.

[0040] The second sending module is used to send the controller system log file to the cloud when a log retrieval instruction is received from the cloud. This allows the cloud or local tools to query all associated communication status records of the communication failure problem from the received communication status record data of the controller system log, based on the mapping relationship between the communication failure problem and the target network communication. Then, according to the hierarchical order of different levels of the target network, the module analyzes the associated communication status record data of each level of all associated communication status record data layer by layer until the cause of the communication failure problem is identified.

[0041] Fifthly, a computer device is provided, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to implement the steps of the vehicle communication fault identification method as described in any one of the present applications.

[0042] In a sixth aspect, a controller is provided, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor, when executing the computer program, implements the steps of the vehicle communication fault identification method as described in any of the preceding claims.

[0043] In a seventh aspect, a vehicle is provided, including a plurality of controllers participating in vehicle Ethernet communication, the controllers being configured to implement the steps of the vehicle communication fault identification method as described in any of the preceding claims.

[0044] Eighthly, a vehicle communication fault identification system is provided, including a vehicle and a cloud, wherein the vehicle includes multiple controllers participating in vehicle target network communication, and the controllers cooperate with the cloud to implement the vehicle communication fault identification method provided in this application.

[0045] Ninthly, a computer-readable storage medium is provided, the computer-readable storage medium storing a computer program, which, when executed by a processor, implements the steps of the vehicle communication fault identification method as described in any of the preceding claims.

[0046] In one of the solutions provided in this application, the system logs of each controller participating in the target network communication in the vehicle are received. These controller system logs include communication status record data for the corresponding controllers. The communication status record data includes communication status information and corresponding time point information for various communication detection types at different levels of the target network. The communication status information includes anomaly markers when anomalies are detected. Therefore, based on the mapping relationship of the problem, all related communication status record data for the communication failure problem can be queried from the communication status record data of the received controller system logs. Then, the related communication status record data at each level of all related communication status record data is analyzed layer by layer until the cause of the communication failure problem is identified. Compared with traditional solutions, this solution eliminates the need for on-site data collection after a communication failure occurs, and also eliminates the need to spend a lot of time reproducing the failure. Online processing improves problem-solving efficiency, reduces the difficulty and threshold of problem investigation, and also improves problem-solving efficiency. Furthermore, it eliminates the need to use traditional data collection tools that damage the original vehicle link; instead, it uses log recall to find the root cause of the failure layer by layer according to the communication level, enabling a thorough resolution of the failure problem and improving problem identification efficiency. Attached Figure Description

[0047] To more clearly illustrate the technical solutions of the embodiments of this application, the drawings used in the description of the embodiments of this application will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0048] Figure 1 This is a schematic diagram of the architecture of a vehicle communication fault identification system according to one embodiment of this application;

[0049] Figure 2 This is a schematic diagram of a communication architecture for vehicle Ethernet communication according to one embodiment of this application;

[0050] Figure 3 yes Figure 2 A detailed interaction diagram of ECU2, ECU1 and ECU4;

[0051] Figure 4 This is a schematic flowchart of a vehicle communication fault identification method according to an embodiment of this application;

[0052] Figure 5 This is a schematic diagram illustrating the layer-by-layer analysis in a vehicle communication fault identification method according to an embodiment of this application;

[0053] Figure 6 This is a schematic diagram of a layer-by-layer analysis operation process in a vehicle communication fault identification method according to an embodiment of this application;

[0054] Figure 7 This is a schematic diagram of a display interface in a vehicle communication fault identification method according to an embodiment of this application;

[0055] Figure 8 This is a schematic diagram of a vehicle communication fault identification device for cloud or local tools according to one embodiment of this application;

[0056] Figure 9 This is a schematic diagram of a vehicle communication fault identification device for a controller in one embodiment of this application;

[0057] Figure 10 This is a schematic diagram of the structure of a controller or computer device according to one embodiment of this application. Detailed Implementation

[0058] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0059] This application provides a vehicle communication fault identification method, applicable to communication fault detection in various vehicles containing target network communication. For example, the target network may be Ethernet or other multi-level communication networks, without specific limitations. For instance, the solution provided in this application can be used for Ethernet communication fault detection in vehicles with Ethernet communication networks. Taking Ethernet as an example, the system framework for implementing this vehicle communication fault identification method can be as follows: Figure 1 As shown, this includes cloud-based (such as cloud-based big data platforms) / local tools, and vehicles participating in the target network. Figure 1 The electronic control unit (ECU) that communicates via Ethernet (taking Ethernet as an example) can include, for instance, vehicle controllers participating in target network communication such as ECU1, ECU2, ECU3, ECU4, ..., ECN, etc. It is worth noting that the embodiments of this application can be implemented based on local tools or the cloud. Local tools can be understood as local tools deployed on the vehicle manufacturer's premises or vehicle-local tools, such as local servers; they can also be implemented based on the cloud, such as cloud big data platforms or ordinary cloud platforms, without any specific limitation.

[0060] Among them, the controllers of the vehicles participating in the target network communication are all deployed with a fault recording application (Ethernet DebugApplication) to implement the functions or methods of the fault recording application on the controller side, and each controller has a corresponding controller system log. Specifically, the controller is used to detect and collect communication status recording data corresponding to various communication detection types at different levels of the target network, and write the collected communication status recording data into its own corresponding controller system log; the communication status recording data includes communication status information and corresponding time point information for various communication detection types.

[0061] please Figure 2 As an example, we will use Ethernet as the target network for illustration. Figure 2 This is a schematic diagram of an architecture model for vehicle Ethernet communication. As an example, it shows the Ethernet communication interaction structure between ECU1, ECU2, ECU3, ECU4, ECU5 and ECU6 in the vehicle that participate in Ethernet communication.

[0062] Combination Figure 3 Taking an example, this section explains the Ethernet communication hierarchy of a vehicle and the Ethernet communication interaction process of several ECUs. Figure 3 That is Figure 2 The diagram illustrates the Ethernet communication interaction process between ECU1, ECU2, and ECU4. Figure 2As shown, ECU1-ECU6 are all equipped with fault recording applications. Each ECU is divided according to an Ethernet communication hierarchy, and the ECUs are connected via Ethernet connections. The internal hardware and software architecture of the controller is divided into several layers. Figure 2 As shown in L1-L5 (a total of 5 layers), the flow of data from the sender to the receiver is marked, including each layer it passes through, forming an Ethernet communication model based on data units. These L1-L5 layers refer to the physical layer, data link layer, system kernel / TCP / IP protocol stack layer, middleware, and entity layer, respectively. Among them, the entity layer refers to the application software or application module installed on the controller (such as the software or module installed on a controller to provide services for a certain vehicle).

[0063] For example, with Figure 2 For example, in ECU1, the physical layer includes transceiver 1_1, transceiver 1_2, and transceiver 1_3. These three transceivers can be used to interact with ECU2, ECU3, and ECU4 respectively. The data link layer includes a switch, which is a core network device that forwards data frames based on the controller's address. The switch includes port 1_1, port 1_2, and port 1_3. ECU2 and ECU4 have the same layer hierarchy, but unlike ECU1, their data link layer uses an Ethernet interface. Figure 2 In the communication interaction diagram, ECU2 has an application entity that needs to send data to ECU4. The communication interaction process is as follows: Figure 2 The curve shows that the transmitted data needs to pass through the middleware layer of ECU2, the system kernel / TCP / IP protocol stack layer, the Ethernet interface, transceiver 2, transceiver 1_1, port 1_1, port 1_3, transceiver 1_3 of ECU1, transceiver 4 of ECU4, the Ethernet interface, the system kernel / TCP / IP protocol stack layer, and the middleware, finally reaching the application entity of ECU4. It is evident that each module along the data path can potentially cause Ethernet communication failures. Therefore, by deploying a fault logging application on each controller, the communication status data corresponding to various communication detection types at different levels of Ethernet communication for each controller can be detected and recorded.

[0064] It should be noted that, Figure 2 and Figure 3 This example uses Ethernet to illustrate its network hierarchy. Other target networks also have corresponding network hierarchy relationships, but no specific restrictions are imposed.

[0065] Additionally, cloud-based or local tools are used to implement cloud-side functions or methods. For example, the cloud can implement the aforementioned cloud-side functions or methods through a big data platform. Specifically, the cloud utilizes a communication failure problem model (such as...). Figure 1 Taking the Ethernet communication fault problem model as an example, by recalling the logs of the above controllers, the system logs of multiple controllers are recalled, the data is reconstructed, and the abnormal data is statistically analyzed by the fault root cause localization system to obtain the communication fault problem and output the fault cause. The fault problem can be pushed to the demand side. For example, the demand side may include the vehicle R&D side, the factory side, or the vehicle 4S store, etc.

[0066] Based on the system framework described above, this application provides a vehicle communication fault identification method. The following describes the vehicle communication fault identification method implemented in this application from multiple perspectives, taking the controller and the cloud as examples, in conjunction with various embodiments.

[0067] like Figure 4 As shown, a method for identifying vehicle communication faults is provided, including the following steps:

[0068] S101: The controller detects the communication status of various communication detection types according to the detection methods of different levels of the target network, so as to obtain the communication status record data of the controller. The communication status record data includes the communication status information of various communication detection types and the corresponding time point information.

[0069] S102: The controller records the communication status data and writes it to the corresponding controller system log file.

[0070] In the vehicle, each controller referencing the target network communication is equipped with a fault recording application. Through this application, the controller can perform the functions or steps of S101-S102 described above. The target network includes Ethernet or other communication models with multi-level networks, and is not specifically limited.

[0071] For example, taking Ethernet as an example, each controller referring to Ethernet communication is deployed with a fault recording application. Through this fault recording application, the controller can implement the functions or steps of S101-S102 mentioned above. This includes detecting the communication status of various communication detection types according to the detection methods of different levels of Ethernet communication, to obtain the controller's communication status recording data. The communication status recording data includes communication status information of various communication detection types and corresponding time point information. The communication status information includes abnormal or normal communication recording data. Abnormalities can be marked by an anomaly marker, that is, the communication status information includes the anomaly marker when an anomaly is detected. As an example, in a specific application, the above-mentioned fault recording application of the controller can be activated after the vehicle is powered on. It is worth noting that the following embodiments will all use Ethernet as an example to describe the processing process of this solution. For other target networks, similar processing is used, and the specifics are not limited.

[0072] by Figure 2-3 The Ethernet communication layer architecture is described below. The vehicle controller includes a multi-layer communication architecture, with each communication layer containing various communication detection types. Each layer can be classified into a primary category, and the different communication detection types within each layer can be classified into secondary categories. In this embodiment, the controller will detect the communication status of various communication detection types according to the detection methods of different communication layers under the Ethernet communication, so as to obtain the controller's communication status record data. The communication status record data includes the communication status information of various communication detection types and the corresponding time point information.

[0073] For example, based on the detection method of the first communication detection type under the first layer of Ethernet communication, the communication status of the first communication detection type will be detected accordingly to obtain the communication status record data of the first communication detection type of the controller. The communication status record data includes the communication status information of the first communication detection type and the corresponding time point information; and so on, to obtain the communication status record data of various communication detection types under all the multiple layers set by the controller.

[0074] It should be noted that in practical applications, different ECUs may use the same or different communication detection types at different levels of Ethernet communication, and this is not limited here; the specific detection location can be initially configured or updated through the fault record application.

[0075] After obtaining the communication status record data from the controller, it writes its own communication status record data into its corresponding controller system log file. For example, after obtaining the aforementioned communication status record data from ECU1, ECU1 writes the communication status record data into its controller system log file. For other ECUs participating in the vehicle Ethernet, a fault recording application is deployed to record the corresponding communication status data and write it into the corresponding controller system log.

[0076] At this point, the vehicle side can obtain multiple controller system logs.

[0077] In one embodiment, the communication status recording data includes the controller's recording data at the following levels under the target network communication:

[0078] Communication status recording data of one or more communication detection types at the physical layer;

[0079] Communication status recording data of one or more communication detection types at the data link layer;

[0080] Communication status recording data for one or more communication detection types in the system kernel / communication protocol stack;

[0081] Communication status recording data of one or more communication detection types in communication middleware.

[0082] For example, with Figure 2-3 The Ethernet communication layer is described in this embodiment. The vehicle Ethernet communication includes a multi-layer communication architecture, including the physical layer, data link layer, system kernel / TCP / IP protocol stack layer, and middleware and application layer. Each layer contains different communication detection types. Each layer can be divided into a category, and the different communication detection types under each layer can be divided into two categories. In this embodiment, the controller will detect the communication status of various communication detection types according to the detection methods of various communication detection types under different Ethernet communication layers, so as to obtain the controller's communication status record data. The communication status record data includes the communication status information of various communication detection types and the corresponding time point information.

[0083] For example, such as:

[0084] For the physical layer, communication detection types may include: 1.1, the link status of each transceiver in the controller; 1.2, the signal quality of each transceiver in the controller; 1.3, ...

[0085] For the data link layer, communication detection types may include: 2.1, the number of flow control frames received / sent by the data link layer interface (such as a switch port or Ethernet interface); 2.2, normal operation records of the switch; 2.3, ...

[0086] For the system kernel / TCP / IP protocol stack, communication detection types may include: 3.1, ping results from the controller; 3.2, ...

[0087] For middleware, communication detection types include: 4.1, controller service status record (for example, taking the SOME / IP SD protocol as an example, obtaining the SOME / IP SD service status); 4.2, ...

[0088] It should be noted that the above-mentioned communication detection types are only illustrative examples in this application. In practical applications, more different communication detection types at different levels can be included. These will not be listed here, nor will they be limited.

[0089] In this embodiment, based on the target network communication architecture, a hierarchical and modular communication model is established forward based on the communication functions (input: service interface flow / network topology / controller hardware and software architecture). Abnormal operating conditions of modules within the communication model are determined hierarchically. This refined hierarchical detection method obtains the necessary massive amounts of recorded data, facilitating subsequent automatic cloud-based statistical analysis and anomaly identification, thereby accurately pinpointing the root cause of each potential fault. It should be noted that the above hierarchical embodiment is merely an example; corresponding communication layering variations are possible in other target network communication architectures, and this application does not limit such variations.

[0090] In one embodiment, the communication status recording data for various communication detection types is recorded by the controller under the condition that the detection preconditions and log recording conditions corresponding to the communication detection type are met.

[0091] In other words, the detection methods for various communication detection types include log recording conditions and detection preconditions. Among them, the detection preconditions refer to the triggering conditions for various communication detection types, and the log recording conditions include the specific data type and time of recording. In this way, the software and hardware modules and abnormal judgment conditions on which each target network communication function depends can be sorted out one by one, thereby establishing clear and specific data acquisition and recording conditions. This is conducive to improving the effectiveness and accuracy of the data recorded in the controller system log, reducing the acquisition and recording of unnecessary data, improving recording efficiency, reducing the power consumption of the controller, and also helping to reduce the difficulty and threshold of subsequent cloud-based problem troubleshooting.

[0092] In one embodiment, the controller's communication status record data is written to the corresponding controller system log by the controller in a preset standard format.

[0093] In this embodiment, each controller system log is written with communication status record data in a unified preset standard format, which is beneficial for reading and managing the data status of the controller system log.

[0094] To facilitate understanding of the acquisition and recording process of the controller's fault log application, in conjunction with the above... Figure 2 Taking ECU1 and Ethernet as examples, as shown in Table 1, the functions or steps implemented by the fault logging application on each controller are illustrated:

[0095]

[0096]

[0097]

[0098]

[0099]

[0100] Table 1

[0101] The following is an explanation of some of the terms used in Table 1 above:

[0102] Ping: Ping is a common method for troubleshooting device access problems. It uses the Internet Control Message Protocol (ICMP) to determine the following: whether the remote device is accessible; whether messages are lost when accessing the remote device; and the round-trip delay between the local end and the remote device.

[0103] Link: Link up means the Ethernet physical layer link is connected; Link down means the Ethernet physical layer link is disconnected.

[0104] SQI: Signal Quality Indication.

[0105] IGN ON: Ignition ON, a power state in a car. It's the state the key is in when the car is normally running; generally, all the car's electrical circuits are active.

[0106] Socket: Also called a socket, it is used to handle network communication connections between different host programs. A socket is represented by a four-tuple (IP address: port).

[0107] Switch: A switch is a device belonging to the data link layer. As a core network device, a switch forwards data frames based on addresses.

[0108] As shown in Table 1, the detection methods for each level and communication detection type include the detection logic, conditions, and parameter configurations. The preconditions, recording conditions, recording formats, and specific parameters (such as the period) in the detection methods for each communication detection type in Table 1 are only illustrative examples in this application and do not constitute a limitation. In practical applications, more detection types at different levels may be included, which will not be illustrated here.

[0109] In one embodiment, the detection methods for each level and communication detection type can be initially configured during the initial configuration of the fault recording application. This initial configuration includes various periods mentioned in Table 1, the IP address to be pinged, and the detection preconditions, all of which are initial configuration values. The periods are configurable; for example, during the trial production stage, the period can be adjusted to 1 second, as shorter periods facilitate problem detection. During mass production, the period can be adjusted to 2 seconds or other values ​​to reduce resource consumption on the controller. This allows the fault recording application of each controller to run based on the initial configuration values ​​to record the aforementioned abnormal data.

[0110] In one embodiment, the method further includes:

[0111] When an update request is received, the vehicle updates the detection method based on the update data, which includes one or more of the following: detection logic, communication detection type, or detection parameters.

[0112] In this embodiment, when an update is needed, the vehicle can upgrade the fault recording application of the controller, thereby updating the detection method based on the updated data. The updated data includes one or more of the following: detection logic, communication detection type, or detection parameters, which facilitates subsequent detection and data recording according to the updated detection method. This allows for the coverage of more types of information that may cause target network communication failures or adaptation to hierarchical architecture updates, thereby continuously improving the entire fault cause analysis scheme. For example, the fault recording application of each controller in the vehicle that participates in target network communication can be upgraded via over-the-air (OTA) updates.

[0113] S103: When the vehicle receives a log recall instruction from the cloud, the controller sends the controller system log file to the cloud.

[0114] S104: The cloud receives controller system logs from each controller in the vehicle that participates in the target network communication.

[0115] S105: Based on the mapping relationship between communication failure issues and target network communication, the cloud queries all associated communication status records of the communication failure issue from the communication status record data received from the controller system log.

[0116] S106: The cloud analyzes the associated communication status record data of each level in all associated communication status record data according to the hierarchical order of different levels of the target network, until the cause of the communication failure is identified.

[0117] First, it's worth noting that steps S103-106 above can also be implemented by local tools. This embodiment only uses the cloud as an example for illustration, and the specific implementation is not limited. Taking this example, for either cloud or local tools, steps S103-107 represent part of the target network communication failure problem model. When it's necessary to analyze the target network communication failure problem or when a specified recall period is met, the cloud or local tool can initiate a log recall, sending a log recall command to the vehicle. This causes the controllers in the vehicle participating in the target network communication to send their corresponding controller system log files to the cloud, ultimately enabling the cloud or local tool to successfully recall multiple controller system logs. If the recall fails, the process continues until the required controller system logs are retrieved. Based on the mapping relationship between communication failures and target network communication, the system retrieves all associated communication status records from the received controller system logs. Using a root cause analysis system, it analyzes the associated communication status records at each level according to the hierarchical relationship of the target network communication to identify the cause of the communication failure until it is determined. The recall period can be a preset value and is not specifically limited.

[0118] It should be understood that, through Figure 2 and Figure 3 As can be seen from the content, taking Ethernet as the target network as an example, communication failures of various communication detection types of Ethernet, that is, vehicle functions related to Ethernet transmission (such as intelligent driving functions, over-the-air upgrade functions, etc.), involve interaction processes between multiple ECUs at various levels. Therefore, the occurrence of communication failures is related to their corresponding communication mapping links. For example, if a certain function A fails, leading to a communication failure, it is necessary to confirm the mapping relationship between function A and Ethernet communication. From the communication status record data of the received controller system log, all related communication status record data of the function failure are queried and the data is reconstructed. Since there are abnormal markers when there are abnormalities, according to the hierarchical relationship of different levels of Ethernet communication, the related communication status record data of each level in all related communication status record data can be analyzed layer by layer to identify the cause of the communication failure, that is, to finally analyze and obtain the cause of the function failure.

[0119] It should be noted that, according to the hierarchical relationship of different layers of the target network, the associated communication status record data of each layer can be analyzed layer by layer to identify the cause of communication failures. This process can be carried out in either a top-down or bottom-up hierarchical order, without limitation. For example, taking the aforementioned Ethernet hierarchical relationship as an example, the hierarchical order can be from L1 to L4 or from L4 to L1, without limitation. The L1-L4 order, which starts the analysis from the physical layer, is the most likely cause of failures because it is the lowest layer. Therefore, in some failure scenarios, this is beneficial for quickly locating the problem and improving the efficiency of failure location.

[0120] For example, with Figure 3 Taking the interaction example shown, the investigation proceeds from bottom to top according to the layered model. During each layer's investigation, data from other layers is masked, and only the data within that layer is analyzed to determine if there are any communication anomaly records. The investigation is carried out sequentially according to the layer order, from L1 to L4, as follows: Figure 5 As shown. Figure 5 As shown, the analysis proceeds sequentially from layer L1 to layer L4. The analysis chain for layer L1 is as follows: ECU2 transceiver 2 → physical media → ECU1 transceiver 1_1 → ECU1 switch → ECU1 transceiver 1_3 → physical media → ECU4; and so on, locating the root cause of the fault layer by layer. If the problem is not located at layer L1, the analysis continues to the next layer, L2, following the chain: ECU2 Ethernet interface (Eth_If2) → ECU1 switch → ECU4 Ethernet interface (Eth_If2); and so on, until layer L4 is reached. In this embodiment, cloud or local tools analyze the associated communication status records from all related communication status records, following the hierarchical relationship of different Ethernet communication levels. This allows for accurate and rapid improvement in fault location efficiency.

[0121] Taking the data recorded in Table 1 as an example, the content of the layer-by-layer analysis includes, for example, the following: Figure 6 The content shown includes analyzing whether a link down has occurred. If so, the result will be "ECUxx and ECUxx Ethernet link disconnected, it is recommended to check the line!"; if not, it will analyze whether SQJ < 0x7 has occurred. If so, the result will be "Poor physical signal quality, it is recommended to check for interference"; and so on, as detailed in the following example. Figure 7 The analytical logic.

[0122] As can be seen, this embodiment provides a vehicle communication fault identification method. This method eliminates the need for on-site data collection after a communication fault occurs, and also avoids spending a lot of time reproducing the fault. Instead, it establishes a hierarchical and modular target network communication fault analysis approach. Based on functional positive transformation, a hierarchical and modular communication fault model is built to identify the abnormal operation indicators of each module at each layer, record the module's operating status and corresponding time points. When a problem occurs, the modules that may affect communication can be quickly and clearly screened, improving the efficiency of problem analysis. Online processing improves the efficiency of problem resolution. The Ethernet technology framework covers all hardware and software modules, and each layer may lead to communication faults. The protocol is complex, and the causes of faults are diverse. Locating the causes of such after-sales problems requires a high level of professional expertise. This solution can reduce the difficulty and threshold of problem investigation, improve the efficiency of problem resolution, and eliminate the need to use traditional data collection tools that damage the original vehicle link. Instead, it uses log recall and cloud-deployed Ethernet communication fault problem models to locate fault problems through data reconstruction and data statistics, improving the efficiency and accuracy of problem location.

[0123] In one embodiment, in step S105, the cloud or local tool, based on the mapping relationship between the communication failure problem and the target network communication, queries all associated communication status record data of the communication failure problem from the communication status record data of the received controller system log, including:

[0124] After the data is reconstructed using cloud or local tools, it is imported into the fault root cause localization system. Based on this system, the cloud or local tools can query all associated communication status records from the received controller system logs, according to the mapping relationship between the communication failure and the target network communication, and the time period of the communication failure.

[0125] In this embodiment, it should be understood that, through Figure 2 and Figure 3 As seen in the Ethernet example, communication failures in various communication detection types of the target network involve interactions between multiple ECUs at different levels. Therefore, the occurrence of communication failures is related to their corresponding communication mapping links. For example, if function A fails, leading to a communication failure, cloud or local tools need to confirm the mapping relationship between function A and the target network communication. They need to query all related communication status records of the function failure from the communication status records in the received controller system logs, and then further filter based on the problem time period to achieve data reorganization. Then, they need to analyze the related communication status records to identify the cause of the communication failure, locate the cause of the failure, and finally analyze the cause of the function failure.

[0126] In this embodiment, cloud or local tools can accurately locate all associated communication status records within a range by using the mapping relationship and time period of communication failure points, thereby reducing the amount of data filtering and improving the efficiency of problem location and analysis.

[0127] In one embodiment, after step S106, which involves the cloud or local tool analyzing the associated communication status record data of each level in all associated communication status record data according to the hierarchical relationship of different levels of the target network communication to identify the cause of the communication failure, the method further includes:

[0128] S107: The cloud or local tools provide a graphical display, in which the graphical display interface shows communication anomaly record data corresponding to communication failures, and the communication anomaly record data is marked in the form of preset tags.

[0129] In this embodiment, the cloud or local tools analyze the associated communication status record data of each level in all associated communication status record data according to the hierarchical relationship of different levels of the target network communication in order to identify the cause of the communication failure problem. The results will continue to be displayed so as to be intuitively shown to the requester.

[0130] In one embodiment, the graphical display interface also displays the cause of the fault, the time of the fault, and the fault hierarchy, and displays the communication anomaly record data and analysis link corresponding to the fault hierarchy.

[0131] For example, such as Figure 6 As shown, Figure 6 This is one example diagram of a graphical user interface. Figure 7 It can be seen that the fault time period is: 2024-05-28 00:00:0020 → 24-05-28 05:00:00; based on the mapping relationship of this fault, the mapping relationship is: ECU2 service 701D → ECU1 switch → ECU4. service 701D represents the communication identifier of this interaction. It can be seen that the analysis link at the L1 layer is: ECU2 transceiver 2 → physical media → ECU1 transceiver 1_1 → ECU1 switch → ECU1 transceiver 1_3 → physical media → ECU4; the communication status record data at 2024-05-28 04:30:01 has no abnormal marker; the communication status record data at 2024-05-28 04:30:01 has an abnormal marker "linkdown", the fault cause is: the Ethernet link between ECU2 and ECU1 is broken, it is recommended to check the line!

[0132] In this embodiment, the graphical display interface also shows the cause of the fault, the time of the fault, and the fault hierarchy, and displays the communication anomaly record data and analysis link corresponding to the fault level, showing more dimensions of fault information and providing a better user experience.

[0133] It should be understood that the sequence number of each step in the above embodiments does not imply the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of this application.

[0134] The above embodiments describe the vehicle communication fault identification method provided in this application from an interactive perspective. The following sections describe the related devices, equipment, systems and media provided in this application.

[0135] In one embodiment, a vehicle communication fault identification device is provided. This device can be used with cloud or local tools, and its functions or steps correspond one-to-one with those implemented by cloud or local tools in a vehicle communication fault identification method described in the above embodiments. Figure 8 As shown, the vehicle communication fault identification device includes a first transmitting module 101, a first receiving module 102, and a first processing module 103. Detailed descriptions of each functional module are as follows:

[0136] The first sending module 101 is used to send a log recall instruction to the vehicle;

[0137] The first receiving module 102 is used to receive the controller system log fed back by the controller response log recall instruction of each controller participating in the target network communication in the vehicle. The controller system log records include the controller's communication status record data. The communication status record data includes communication status information and corresponding time point information of various communication detection types at different levels of the target network. The communication status information includes anomaly markers when anomalies are detected.

[0138] The first processing module 103 is used to query all associated communication status record data of the communication failure problem from the communication status record data of the received controller system log according to the mapping relationship between the communication failure problem and the target network communication; and to analyze the associated communication status record data of each level in all associated communication status record data layer by layer according to the hierarchical order relationship of different levels of the target network until the cause of the communication failure problem is identified.

[0139] In conjunction with the above embodiments, in one embodiment, the communication status recording data includes the controller's recording data at the following levels under target network communication:

[0140] Communication status recording data of one or more communication detection types at the physical layer;

[0141] Communication status recording data of one or more communication detection types at the data link layer;

[0142] Communication status recording data for one or more communication detection types in the system kernel / communication protocol stack;

[0143] Communication status recording data of one or more communication detection types in communication middleware.

[0144] Based on the above embodiments, the hierarchical order is as follows: physical layer, data link layer, system kernel / communication protocol stack, and communication middleware.

[0145] In conjunction with the above embodiments, the first processing module 103 is further configured to:

[0146] Based on the mapping relationship between communication failures and target network communication, and the time period of the communication failures, all associated communication status records of the communication failures are retrieved from the communication status records in the received controller system logs.

[0147] In conjunction with the above embodiments, in one embodiment, a display module is further included, which is used for:

[0148] The system provides a graphical display, which shows communication anomaly records corresponding to communication failures, and these records are marked with preset tags.

[0149] In one embodiment, the communication status recording data for various communication detection types is recorded by the controller under the condition that the detection preconditions and log recording conditions corresponding to the communication detection type are met.

[0150] In one embodiment, a vehicle communication fault identification device is provided. This device can be used in a controller, and its functions or steps correspond one-to-one with the fault recording application of the controller in the vehicle communication fault identification method described in the above embodiments. For example... Figure 9 As shown, the vehicle communication fault identification device includes a second processing module 201 and a second transmitting module 202. Detailed descriptions of each functional module are as follows:

[0151] The second processing module 201 is used to detect the communication status of various communication detection types according to the detection methods of various communication detection types under different layers of the target network, so as to obtain the communication status record data of the controller. The communication status record data includes the communication status information of various communication detection types and the corresponding time point information; and writes the communication status record data into the corresponding controller system log file. The communication status information includes the exception marker when an exception is detected.

[0152] The second sending module 202 is used to send the controller system log file to the cloud when the vehicle receives the log recall instruction from the cloud. This allows the cloud or local tools to query all related communication status record data of the communication failure problem from the communication status record data of the received controller system log, based on the mapping relationship between the communication failure problem and the target network communication. The cloud or local tools then analyze the related communication status record data of each level in all related communication status record data layer by layer according to the hierarchical order of different levels of the target network communication, until the cause of the communication failure problem is identified.

[0153] In one embodiment, the second processing module 201 is further configured to:

[0154] When an update request is received, the detection method is updated based on the update data. The update data includes one or more of the following: detection logic, communication detection type, or detection parameters.

[0155] In one embodiment, the communication status recording data includes recording data from the controller at the following levels in the target network:

[0156] Communication status recording data of one or more communication detection types at the physical layer;

[0157] Communication status recording data of one or more communication detection types at the data link layer;

[0158] Communication status recording data for one or more communication detection types in the system kernel / communication protocol stack;

[0159] Communication status recording data of one or more communication detection types in communication middleware.

[0160] In one embodiment, the communication status recording data for various communication detection types is recorded by the controller under the condition that the detection preconditions and log recording conditions corresponding to the communication detection type are met.

[0161] As can be seen, this embodiment provides a vehicle communication fault identification device that eliminates the need to travel to the site to collect data after a communication fault occurs, and also eliminates the need to spend a lot of time reproducing the fault. The online nature of the device improves the efficiency of problem solving, reduces the difficulty and threshold of problem investigation, and also improves the efficiency of problem solving. It also eliminates the need to use traditional data collection tools that damage the original vehicle link, but instead uses log recall and cloud-deployed Ethernet communication fault problem models to locate fault problems through data reconstruction and data statistics, thereby improving the efficiency and accuracy of problem location.

[0162] For specific limitations regarding the vehicle communication fault identification device, please refer to the limitations on controllers, cloud-based or local tools in the vehicle communication fault identification method mentioned above, which will not be repeated here. Each module in the aforementioned vehicle communication fault identification device can be implemented entirely or partially through software, hardware, or a combination thereof. These modules can be embedded in or independent of the processor in the electronic device in hardware form, or stored in the memory of the electronic device in software form, so that the processor can call and execute the corresponding operations of each module. For example, they can be written into the controller in the form of software code.

[0163] In one embodiment, a controller is provided, the internal structure of which can be shown in the diagram below. Figure 10 As shown. The controller includes a processor, memory, and network interface connected via a system bus. The processor provides computing and control capabilities. The memory includes a non-volatile storage medium and internal memory. The non-volatile storage medium stores an operating system and computer programs. The internal memory provides an environment for the operation of the operating system and computer programs in the non-volatile storage medium. The processor's network interface is used to communicate with cloud or local tools via a network connection for the exchange of instructions / data. When executed by the processor, the computer program implements the steps or functions of the controller in a vehicle communication fault identification method according to any embodiment of this application.

[0164] In one embodiment, a controller is provided, including a memory, a processor, and a computer program stored in the memory and executable on the processor. When the processor executes the computer program, it implements the steps or functions of the controller in a vehicle communication fault identification method provided in any embodiment of this application.

[0165] In one embodiment, a computer-readable storage medium is provided, which stores a computer program that, when executed by a processor, implements the steps or functions of the controller in a vehicle communication fault identification method according to any embodiment of this application.

[0166] In one embodiment, a computer device is provided, which can be a cloud-based or local tool, and its internal structure diagram can be as follows. Figure 10As shown. The controller includes a processor, memory, and network interface connected via a system bus. The processor provides computing and control capabilities. The memory includes a non-volatile storage medium and internal memory. The non-volatile storage medium stores an operating system and computer programs. The internal memory provides an environment for the operation of the operating system and computer programs in the non-volatile storage medium. The network interface of the processor is used for vehicle / controller communication via a network connection to achieve the interaction of relevant instructions / data. When the computer program is executed by the processor, it implements the steps or functions of the cloud or local tools in a vehicle communication fault identification method according to any embodiment of this application.

[0167] In one embodiment, a cloud-based or local tool is provided, including a memory, a processor, and a computer program stored in the memory and executable on the processor. When the processor executes the computer program, it implements the steps / functions of the cloud-based or local tool in a vehicle communication fault identification method provided in any embodiment of this application.

[0168] In one embodiment, a computer-readable storage medium is provided, which stores a computer program. When executed by a processor, the computer program implements the steps / functions of a cloud-based or local tool in a vehicle communication fault identification method according to any embodiment of this application.

[0169] In one embodiment, a vehicle is provided, including a plurality of controllers participating in vehicle target network communication. The controllers are used to implement the steps or functions of the controller in a vehicle communication fault identification method as described in any embodiment of this application. For example, the target network includes Ethernet.

[0170] In one embodiment, a vehicle communication fault identification system is provided, including a vehicle and a cloud. The vehicle includes multiple controllers that participate in vehicle target network communication. The controllers are used to implement the steps or functions of the controller in any embodiment of the vehicle communication fault identification method of this application. The cloud is used to implement the steps / functions of the cloud in any embodiment of the vehicle communication fault identification method of this application. The controllers and the cloud are configured to implement the vehicle communication fault identification method provided in the embodiments of this application.

[0171] Those skilled in the art will understand that all or part of the processes in the methods of the above embodiments can be implemented by a computer program instructing related hardware. The computer program can be stored in a non-volatile computer-readable storage medium, and when executed, it can include the processes of the embodiments of the above methods. Any references to memory, storage, databases, or other media used in the embodiments provided in this application can include non-volatile and / or volatile memory. Non-volatile memory can include read-only memory (ROM), programmable ROM (PROM), electrically programmable ROM (EPROM), electrically erasable programmable ROM (EEPROM), or flash memory. Volatile memory can include random access memory (RAM) or external cache memory. By way of illustration and not limitation, RAM is available in various forms, such as static RAM (SRAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), dual data rate SDRAM (DDRSDRAM), enhanced SDRAM (ESDRAM), synchronous link DRAM (SLDRAM), Rambus direct RAM (RDRAM), direct memory bus dynamic RAM (DRDRAM), and memory bus dynamic RAM (RDRAM), etc.

[0172] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the above-described division of functional units and modules is used as an example. In practical applications, the above functions can be assigned to different functional units and modules as needed, that is, the internal structure of the device can be divided into different functional units or modules to complete all or part of the functions described above.

[0173] The above-described embodiments are only used to illustrate the technical solutions of this application, and are not intended to limit them. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of this application, and should all be included within the protection scope of this application.

Claims

1. A method for identifying vehicle communication faults, characterized in that, include: The system receives controller system logs fed back by the controllers of each target network communication in the vehicle. The controller system logs include communication status record data of the corresponding controllers. The communication status record data includes communication status information and corresponding time point information of various communication detection types at different levels of the target network. The communication status information includes anomaly markers when anomalies are detected. Based on the mapping relationship between the communication failure problem and the target network communication, all associated communication status record data of the communication failure problem are retrieved from the communication status record data of the received controller system log. According to the hierarchical order of the target network, the associated communication status record data of each level in all associated communication status record data is analyzed layer by layer until the cause of the communication failure is identified.

2. The vehicle communication fault identification method as described in claim 1, characterized in that, The communication status recording data includes the following hierarchical recording data of the controller under the target network communication: Communication status recording data of one or more communication detection types at the physical layer; Communication status recording data of one or more communication detection types at the data link layer; Communication status recording data for one or more communication detection types in the system kernel / communication protocol stack; Communication status recording data of one or more communication detection types in communication middleware.

3. The vehicle communication fault identification method as described in claim 2, characterized in that, The hierarchical order is as follows: physical layer, data link layer, system kernel / communication protocol stack, and communication middleware.

4. The vehicle communication fault identification method as described in claim 1, characterized in that, The step of querying all associated communication status records of the communication failure problem from the communication status record data received from the controller system log, based on the mapping relationship between the communication failure problem and the target network communication, includes: Based on the mapping relationship between the communication failure and the target network communication, and the time period of the communication failure, all associated communication status records of the communication failure are retrieved from the communication status record data received from the controller system log.

5. The vehicle communication fault identification method as described in claim 1, characterized in that, After analyzing the associated communication status record data at each level of all associated communication status record data according to the hierarchical relationship of the target network to identify the cause of the communication failure, the method further includes: A graphical display is provided, wherein the graphical display interface displays communication anomaly record data corresponding to the communication failure problem, and the communication anomaly record data is marked in the form of preset tags.

6. The vehicle communication fault identification method as described in claim 1, characterized in that, The communication status recording data for various communication detection types includes the corresponding detection preconditions and log recording conditions.

7. The vehicle communication fault identification method according to any one of claims 1-6, characterized in that, The communication status record data of the controller is stored in the controller system log in a preset standard format.

8. A method for identifying vehicle communication faults, characterized in that, include: The detection method detects the communication status of various communication detection types under different levels of the target network communication, and obtains the communication status record data of the controller. The communication status record data includes the communication status information of various communication detection types and the corresponding time point information. The communication status information includes the abnormality mark when an abnormality is detected. The communication status record data is written to the corresponding controller system log file; When a log retrieval instruction is received from a cloud or local tool, the controller system log file is sent to the cloud or local tool. This allows the cloud or local tool to query all associated communication status records of the communication failure from the received controller system log communication status record data, based on the mapping relationship between the communication failure and the target network communication. Then, following the hierarchical order of different levels of the target network, the tool analyzes the associated communication status record data at each level of all associated communication status record data layer by layer until the cause of the communication failure is identified.

9. The vehicle communication fault identification method as described in claim 8, characterized in that, The method further includes: When an update request is received, the detection method is updated according to the update data, which includes one or more of the following: detection logic, communication detection type, or detection parameters.

10. The vehicle communication fault identification method as described in claim 8, characterized in that, The communication status record data includes the following hierarchical record data under the target network communication: Communication status recording data of one or more communication detection types at the physical layer; Communication status recording data of one or more communication detection types at the data link layer; Communication status recording data for one or more communication detection types in the system kernel / communication protocol stack; Communication status recording data of one or more communication detection types in communication middleware.

11. The vehicle communication fault identification method according to any one of claims 8-10, characterized in that, The communication status record data for various communication detection types are obtained based on the detection preconditions and log recording conditions corresponding to the communication detection type.

12. A vehicle communication fault identification device, characterized in that, For use in the cloud, the device includes: The first sending module is used to send log recall instructions to the vehicle; The first receiving module is used to receive the controller system logs fed back by each controller participating in the target network communication in the vehicle in response to the log recall instruction. The controller system log records include the controller's communication status record data. The communication status record data includes communication status information and corresponding time point information for various communication detection types at different levels of the target network. The communication status information includes anomaly markers when anomalies are detected. The first processing module is used to query all associated communication status record data of the communication failure problem from the communication status record data of the received controller system log according to the mapping relationship between the communication failure problem and the target network communication; and to analyze the associated communication status record data of each level in all associated communication status record data layer by layer according to the hierarchical order relationship of different levels of the target network until the cause of the communication failure problem is identified.

13. A vehicle communication fault identification device, characterized in that, For use with a controller, the device includes: The second processing module is used to detect the communication status of various communication detection types according to the detection methods of various communication detection types under different layers of the target network, so as to obtain the communication status record data of the controller. The communication status record data includes the communication status information of various communication detection types and the corresponding time point information; and writes the communication status record data into the corresponding controller system log file. The communication status information includes the exception marker when an exception is detected. The second sending module is used to send the controller system log file to the cloud when a log retrieval instruction is received from the cloud. This allows the cloud or local tools to query all associated communication status records of the communication failure problem from the received communication status record data of the controller system log, based on the mapping relationship between the communication failure problem and the target network. Then, the modules analyze the associated communication status record data of each level in all associated communication status record data layer by layer according to the hierarchical order of different levels of the target network, until the cause of the communication failure problem is identified.

14. A computer device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, When the processor executes the computer program, it implements the steps of the vehicle communication fault identification method as described in any one of claims 1 to 7.

15. A controller comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, When the processor executes the computer program, it implements the steps of the vehicle communication fault identification method as described in any one of claims 8 to 11.

16. A vehicle comprising a plurality of controllers participating in vehicle Ethernet communication, characterized in that, The controller is used to implement the steps of the vehicle communication fault identification method as described in any one of claims 5 to 8.

17. A vehicle communication fault identification system, comprising a vehicle and a cloud, wherein the vehicle includes multiple controllers participating in vehicle-to-target network communication, characterized in that, The controller is used to implement the steps of the vehicle communication fault identification method as described in any one of claims 8 to 11, and the cloud is used to implement the steps of the vehicle communication fault identification method as described in any one of claims 1 to 7.

18. A computer-readable storage medium storing a computer program, characterized in that, When the computer program is executed by a processor, it implements the steps of the vehicle communication fault identification method as described in any one of claims 1 to 11.

Images