Vehicle communication fault identification method and related apparatus

Abstract

The present application relates to the technical field of vehicles, and particularly discloses a vehicle communication fault identification method and apparatus, a device, a controller, a system, and a medium, used for improving the vehicle communication fault identification efficiency. The method comprises: receiving a controller system log fed back by each controller participating in target network communication in a vehicle, wherein 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 at different levels of a target network, and the communication state information comprises an anomaly mark when an anomaly is detected; querying all the associated communication state record data of a communication fault problem from the communication state record data of the received controller system logs; and analyzing the associated communication state record data of each level in all the associated communication state record data layer by layer until a fault cause of the communication fault problem is identified.

Description

Vehicle communication fault identification method and related devices

[0001] This application claims priority to Chinese Patent Application No. 202411191705.6, filed on August 27, 2024, entitled “Vehicle Communication Fault Identification Method and Related Device”, the entire contents of which are incorporated herein by reference. Technical Field

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[0017] 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:

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

[0019] 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:

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

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

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

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

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

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

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

[0027] Furthermore, the method also includes:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[0047] 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 complete solution to the failure problem and improving problem identification efficiency.

[0048] Details of one or more embodiments of this application are set forth in the following drawings and description, and other features and advantages of this application will become apparent from the specification, drawings and claims. Attached Figure Description

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

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

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

[0052] Figure 3 is a schematic diagram of the specific interaction between ECU2, ECU1 and ECU4 in Figure 2;

[0053] Figure 4 is a flowchart illustrating a vehicle communication fault identification method according to an embodiment of this application.

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

[0055] Figure 6 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;

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

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

[0058] Figure 9 is a schematic diagram of a vehicle communication fault identification device for a controller according to an embodiment of this application;

[0059] Figure 10 is a schematic diagram of a controller or computer device according to an embodiment of this application. Detailed Implementation

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

[0061] This application provides a vehicle communication fault identification method, applicable to the detection of communication faults in various vehicles involving target network communication. For example, the target network could 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 is shown in Figure 1, including cloud (e.g., a cloud big data platform) / local tools, and an electronic control unit (ECU) that participates in the vehicle's communication with the target network (Ethernet is used as an example in Figure 1). For example, the vehicle controller participating in the target network communication may include ECU1, ECU2, ECU3, ECU4, ..., ECN, etc. It is worth noting that this application can be implemented based on local tools or the cloud. Local tools can be understood as tools deployed on the vehicle manufacturer's premises or vehicle-specific tools, such as a local server; it can also be implemented based on the cloud, such as a cloud big data platform or a regular cloud platform, without specific limitations.

[0062] Among them, the controllers of the vehicles participating in the target network communication are all deployed with a fault recording application (Ethernet Debug Application) 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.

[0063] Please refer to Figure 2 as an example, taking Ethernet as the target network for illustration. Figure 2 is a schematic diagram of an architecture model of vehicle Ethernet communication. Here, as an example, a schematic diagram of the Ethernet communication interaction structure between ECU1, ECU2, ECU3, ECU4, ECU5 and ECU6 in the vehicle participating in Ethernet communication is given.

[0064] Using Figure 3 as an example, this section explains the Ethernet communication hierarchy of a vehicle and the Ethernet communication interaction process between several ECUs. Figure 3 illustrates the Ethernet communication interaction process between ECU1, ECU2, and ECU4 in Figure 2. As shown in Figure 2, ECU1-ECU6 all have fault recording applications deployed. Each ECU is divided according to the Ethernet communication hierarchy, and the ECUs are connected via Ethernet connections. The controller's internal hardware and software architecture is divided into several layers (L1-L5, a total of 5 layers shown in Figure 2). The flow of data from the sender to the receiver is marked, including each layer traversed, 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. The entity layer refers to the application software or application modules installed on the controller (e.g., software or modules installed on a controller to provide services for a specific vehicle).

[0065] For example, taking Figure 2 as an 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 device belonging to the data link layer. As a core network device, the switch 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. In the communication interaction diagram in Figure 2, an application entity in ECU2 needs to send data to ECU4. The communication interaction process follows the curve shown in Figure 2. The data to be sent must 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 in ECU4. It is evident that each module in each layer through which the data passes can potentially cause Ethernet communication failures. Therefore, by deploying a fault logging application on each controller, the detection and recording of communication status data corresponding to various communication detection types at different levels of Ethernet communication for the corresponding controller can be achieved.

[0066] It should be noted that Figures 2 and 3 are only examples of Ethernet to illustrate its network hierarchy. Other target networks also have corresponding network hierarchy relationships, which are not specifically limited.

[0067] In addition, cloud or local tools are used to implement cloud-side functions or methods. For example, the cloud can implement the above-mentioned cloud-side functions or methods through a big data platform. Specifically, the cloud uses a communication fault problem model (as shown in Figure 1, which uses an Ethernet communication fault problem model as an example) to recall the logs of the above-mentioned controllers, then reassembles the data, and then uses a fault root cause location system to statistically analyze abnormal data to obtain the communication fault problem and output the fault cause. The fault problem can be pushed to the requesting party. For example, the requesting party may include the vehicle R&D side, the factory side, or the vehicle 4S store, etc.

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

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

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

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

[0072] 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 to any particular model.

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

[0074] The vehicle controller, as illustrated in Figure 2-3, comprises a multi-level communication architecture. Each communication level contains various communication detection types. Each level can be classified into a primary category, and the different communication detection types within each level can be further classified into secondary categories. In this embodiment, the controller detects the communication status of various communication detection types according to their detection methods at different Ethernet communication levels, thereby obtaining the controller's communication status record data. This data includes communication status information for each communication detection type and corresponding time point information.

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

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

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

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

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

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

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

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

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

[0084] For example, as illustrated in Figure 2-3, the vehicle Ethernet communication in this embodiment includes a multi-layered 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, and each layer can be classified into a category. The different communication detection types under 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 various communication detection types under different layers of 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.

[0085] For example, such as:

[0086] 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, ...

[0087] 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, ...

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

[0089] 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, ...

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

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

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

[0093] 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 troubleshooting.

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

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

[0096] To facilitate understanding of the acquisition and recording process of the controller's fault logging application, and referring to Figure 2 above, using ECU1 and Ethernet as an example, we illustrate the functions or steps implemented by the fault logging application on each controller, as shown in Table 1:

[0097] Table 1

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

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

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

[0101] SQI: Signal Quality Indication.

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

[0103] 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).

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

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

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

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

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

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

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

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

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

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

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

[0115] It should be understood that, as shown in Figures 2 and 3, 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 (e.g., including but not limited to intelligent driving functions, over-the-air updates, 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 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 received from the controller system log, all related communication status record data of the function failure can be retrieved and the data 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.

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

[0117] For example, taking the interaction example shown in Figure 3, the investigation proceeds layer by layer from bottom to top according to the hierarchical model. During each layer's investigation, data from other layers is masked, and only the data in the current layer is analyzed to see if there are any communication anomaly records. The investigation logic from layer L1 to layer L4 is shown in Figure 5. As shown in Figure 5, starting from layer L1, the analysis proceeds sequentially up 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, i.e., layer L2, with the following 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 record data of each level in all associated communication status record data according to the hierarchical relationship of different Ethernet communication levels, thereby accurately and quickly improving the efficiency of fault location.

[0118] Taking the data recorded in Table 1 as an example, the layer-by-layer analysis includes the content shown in Figure 6, which 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 shown in the analysis logic in Figure 7.

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

[0120] 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:

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

[0122] In this embodiment, it should be understood that, as shown in the Ethernet examples in Figures 2 and 3, communication failures of various communication detection types in the target network involve interactions between multiple ECUs at different levels. Therefore, the occurrence of a communication failure is related to its corresponding communication mapping link. 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. From the communication status record data received from the controller system log, all related communication status record data of the function failure are queried out. Then, based on the problem time period, further filtering is performed to achieve data reorganization. The related communication status record data is then analyzed to identify the cause of the communication failure, locate the cause of the failure, and finally analyze the cause of the function failure.

[0123] In this embodiment, cloud-based or local tools can accurately locate all associated communication status records within a range by utilizing 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.

[0124] 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:

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

[0126] In this embodiment, 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 intuitively show the requester.

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

[0128] For example, as shown in Figure 6, which is an example of a graphical display interface, Figure 7 shows 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 "link down". The cause of the fault is: the Ethernet link between ECU2 and ECU1 is broken. It is recommended to check the line!

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

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

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

[0132] 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 the vehicle communication fault identification method described in the above embodiments. As shown in FIG8, the vehicle communication fault identification device includes a first sending module 101, a first receiving module 102, and a first processing module 103. Detailed descriptions of each functional module are as follows:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[0147] 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 embodiment. As shown in Figure 9, the vehicle communication fault identification device includes a second processing module 201 and a second sending module 202. Detailed descriptions of each functional module are as follows:

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

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

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

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

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

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

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

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

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

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

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

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

[0160] In one embodiment, a controller is provided, the internal structure of which can be shown in Figure 10. The controller includes a processor, a memory, and a 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 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 controller in a vehicle communication fault identification method according to any embodiment of this application.

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

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

[0163] In one embodiment, a computer device is provided, which can be a cloud-based or local tool, and its internal structure diagram is shown in Figure 10. The controller includes a processor, memory, and a 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-based or local tool in a vehicle communication fault identification method according to any embodiment of this application.

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

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

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

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

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

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

[0170] 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, wherein, 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, wherein, 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, wherein, 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, wherein, 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, wherein, 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, wherein, 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, wherein, 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, wherein, 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, wherein, 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, wherein, 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, wherein, 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, wherein, 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, wherein, For 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, wherein, 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, wherein, 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, wherein, 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, 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, wherein, 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