Vehicle-mounted remote communication terminal Ethernet fault recovery method and device, and storage medium

Abstract

The invention discloses a vehicle-mounted remote communication terminal Ethernet fault recovery method and device and a storage medium, and relates to the technical field of communication, and the method comprises the steps: in the communication process of a vehicle-mounted remote communication terminal, if the connection state of a transmission control protocol is abnormal, obtaining the accessibility of a central electronic module; under the condition that the reachability of the central electronic module is in a reachability state, determining a first target fault recovery strategy based on the reachability of the man-machine interaction terminal, the abnormal condition of an address resolution protocol cache table related to the man-machine interaction terminal and the loss condition of multicast routing, so as to perform fault recovery based on the first target fault recovery strategy; and under the condition that the reachability of the central electronic module is in an unreachable state, determining a second target fault recovery strategy based on an abnormal condition of an address resolution protocol cache table related to the central electronic module, and performing fault recovery based on the second target fault recovery strategy. According to the method, the fault recovery efficiency and success rate can be improved.

Description

Technical Field

[0001] This application relates to the field of communication technology, and in particular to a method for recovering Ethernet faults in a vehicle-mounted remote communication terminal, a computer-readable storage medium, a vehicle, and a device for recovering Ethernet faults in a vehicle-mounted remote communication terminal. Background Technology

[0002] With the widespread application of automotive Ethernet in intelligent connected vehicles, in-vehicle TBoxes (vehicle remote communication terminals) need to adapt to various heterogeneous hardware platforms. However, Ethernet chips on different platforms exhibit significant differences in key parameters such as driver loading methods (kernel autoloading / KO (Kernel Object) module loading (loadable modules in the Linux kernel)) and power control location (MCU (Microcontroller Unit) / SOC (System on Chip) side). This difference leads to poor platform compatibility. Traditional recovery strategies cannot adapt to the driver loading, reset mechanisms, and power control interfaces of different PHY chips. Furthermore, current fault recovery strategies for TBox communication are not efficient enough, failing to quickly and accurately locate and resolve problems, resulting in long recovery times. For example, frequent resets of the PHY (Physical Layer Chip) chip may cause hardware damage, and recovery strategies lack specificity. Similarly, performing a physical reset for cable disconnection (physical fault) is wasteful and ineffective. Summary of the Invention

[0003] This application aims to at least partially address one of the technical problems in the related art. Therefore, the first objective of this application is to propose a method for Ethernet fault recovery in vehicle-mounted remote communication terminals, which can quickly and accurately locate the level of the problem and execute targeted recovery measures, avoiding blind recovery operations and improving the efficiency and success rate of fault recovery.

[0004] The second objective of this application is to provide a computer-readable storage medium.

[0005] The third objective of this application is to propose a vehicle.

[0006] The fourth objective of this application is to provide an Ethernet fault recovery device for an in-vehicle remote communication terminal.

[0007] To achieve the above objectives, a first aspect of this application proposes a method for Ethernet fault recovery of a vehicle-mounted remote communication terminal. During communication by the vehicle-mounted remote communication terminal, if the connection status of the transmission control protocol is abnormal, the reachability of the central electronic module is obtained. If the central electronic module is reachable, a first target fault recovery strategy is determined based on the reachability of the human-machine interface terminal, the abnormality of the address resolution protocol cache table associated with the human-machine interface terminal, and the loss of multicast routes, and fault recovery is performed based on the first target fault recovery strategy. If the central electronic module is unreachable, a second target fault recovery strategy is determined based on the abnormality of the address resolution protocol cache table associated with the central electronic module, and fault recovery is performed based on the second target fault recovery strategy.

[0008] The Ethernet fault recovery method for vehicle-mounted remote communication terminals according to the embodiments of this application can quickly and accurately locate the level of the problem and execute targeted recovery measures, avoiding blind recovery operations and improving the efficiency and success rate of fault recovery.

[0009] In addition, the vehicle-mounted remote communication terminal Ethernet fault recovery method according to the above embodiments of this application may also have the following additional technical features: According to one embodiment of this application, determining the first target fault recovery strategy based on the reachability of the human-machine interaction terminal, the abnormality of the address resolution protocol cache table related to the human-machine interaction terminal, and the loss of multicast routes includes: when the reachability of the human-machine interaction terminal is reachable and the address resolution protocol cache table related to the human-machine interaction terminal is abnormal, determining the first target fault recovery strategy to receive static target address resolution protocol entries related to the human-machine interaction terminal; when the reachability of the human-machine interaction terminal is unreachable and the multicast route is lost, determining the first target fault recovery strategy to receive static multicast routes; when the reachability of the human-machine interaction terminal is unreachable and the multicast route is not lost, if monitoring the vehicle communication protocol reveals a multicast subscription failure event, then determining the first target fault recovery strategy to restart the application layer service module.

[0010] According to one embodiment of this application, determining the second target fault recovery strategy based on the abnormality of the address resolution protocol cache table related to the central electronic module includes: when the address resolution protocol cache table related to the central electronic module is abnormal, determining the second target fault recovery strategy as receiving static target address resolution protocol entries related to the central electronic module; when the address resolution protocol cache table related to the central electronic module is normal and the number of times the second target fault recovery strategy is executed is less than a preset number, determining the second target fault recovery strategy as a first fault reset strategy.

[0011] According to one embodiment of this application, the first fault reset strategy includes: when a first target reset duration is reached, sending a reset instruction to the target register of the physical layer chip and obtaining the Ethernet connection status after sending the reset instruction, wherein the reset instruction is used to trigger the reset of the physical layer chip to restore the target register to its initial state; when the connection status is an Ethernet disconnected state or an unknown Ethernet connection status, powering off and restarting the physical layer chip based on the target operation, wherein the target operation includes controlling the power supply pins of the physical layer chip based on a microcontroller or system-on-a-chip; after powering off and restarting the physical layer chip and when the connection status is the Ethernet disconnected state or the unknown Ethernet connection status, unloading and reloading the driver program corresponding to the physical layer chip.

[0012] According to one embodiment of this application, the method further includes: acquiring the connection status of the Ethernet, wherein the connection status of the Ethernet includes an Ethernet disconnected state and an unknown Ethernet connection state; when the connection status of the Ethernet is the unknown Ethernet connection state, performing fault recovery based on a third target fault recovery strategy, wherein the third target fault recovery strategy is to periodically execute a second fault reset strategy; when the connection status of the Ethernet is the Ethernet disconnected state, acquiring the cable status of the Ethernet cable, and when the cable status is normal, performing fault recovery based on a fourth target fault recovery strategy, wherein the fourth target fault recovery strategy is to execute the second fault reset strategy once.

[0013] According to one embodiment of this application, the second fault reset strategy includes: when a second target reset duration is reached, sending a reset instruction to the target register of the physical layer chip and obtaining the Ethernet connection status after sending the reset instruction, wherein the reset instruction is used to trigger the reset of the physical layer chip to restore the target register to its initial state; when the connection status is the Ethernet disconnected state or the unknown Ethernet connection status, powering off and restarting the physical layer chip through the target operation, wherein the target operation includes controlling the power pins of the physical layer chip through a microcontroller or system-on-a-chip.

[0014] According to one embodiment of this application, the method further includes: obtaining the sum of the number of times the Ethernet connection failed after sending the reset command and after power-off restarting the physical layer chip; determining a target preset duration based on the sum of the number of failures and a preset mapping relationship, wherein the preset mapping relationship is used to indicate the relationship between the sum of the number of failures and the target preset duration; updating the second target reset duration based on the target preset duration to reduce the frequency of periodically executing the second fault reset strategy.

[0015] To achieve the above objectives, a second aspect of this application provides a computer-readable storage medium storing a program that, when executed by a processor, implements the above-described method for Ethernet fault recovery of a vehicle-mounted remote communication terminal.

[0016] The computer-readable storage medium according to the embodiments of this application implements the above-described vehicle-mounted remote communication terminal Ethernet fault recovery method during execution, which can quickly and accurately locate the level of the problem and perform targeted recovery measures, avoiding blind recovery operations and improving the efficiency and success rate of fault recovery.

[0017] To achieve the above objectives, a vehicle is provided in the third aspect of this application, including a memory, a processor, and a program stored in the memory and executable on the processor. When the processor executes the program, it implements the above-described method for Ethernet fault recovery of a vehicle-mounted remote communication terminal.

[0018] According to the embodiments of this application, by executing the above-described vehicle-mounted remote communication terminal Ethernet fault recovery method, the vehicle can quickly and accurately locate the level of the problem and execute targeted recovery measures, avoiding blind recovery operations and improving the efficiency and success rate of fault recovery.

[0019] To achieve the above objectives, a fourth aspect of this application provides an Ethernet fault recovery device for a vehicle-mounted remote communication terminal. The device includes: an acquisition module, configured to acquire the reachability of a central electronic module if the connection status of the transmission control protocol is abnormal during communication of the vehicle-mounted remote communication terminal; a first fault recovery module, configured to determine a first target fault recovery strategy based on the reachability of a human-machine interface terminal, anomalies in the address resolution protocol cache table associated with the human-machine interface terminal, and the loss of multicast routes, when the central electronic module is reachable, and to perform fault recovery based on the first target fault recovery strategy; and a second fault recovery module, configured to determine a second target fault recovery strategy based on anomalies in the address resolution protocol cache table associated with the central electronic module, when the central electronic module is unreachable, and to perform fault recovery based on the second target fault recovery strategy.

[0020] The vehicle-mounted remote communication terminal Ethernet fault recovery device according to the embodiments of this application can quickly and accurately locate the level of the problem and perform targeted recovery measures, avoiding blind recovery operations and improving the efficiency and success rate of fault recovery.

[0021] Additional aspects and advantages of this application will be set forth in part in the description which follows, and in part will be obvious from the description, or may be learned by practice of this application. Attached Figure Description

[0022] Figure 1 This is a flowchart of a method for recovering Ethernet faults in a vehicle-mounted remote communication terminal according to an embodiment of this application.

[0023] Figure 2 This is a flowchart illustrating a specific example of an Ethernet fault recovery method for an in-vehicle remote communication terminal according to this application.

[0024] Figure 3 This is a block diagram of a vehicle according to an embodiment of this application.

[0025] Figure 4 This is a block diagram of an Ethernet fault recovery device for an in-vehicle remote communication terminal according to an embodiment of this application. Detailed Implementation

[0026] The embodiments of this application are described in detail below. Examples of these embodiments are shown in the accompanying drawings, wherein the same or similar reference numerals denote the same or similar elements or elements having the same or similar functions throughout. The embodiments described below with reference to the accompanying drawings are exemplary and intended to explain this application, and should not be construed as limiting this application.

[0027] The following description, with reference to the accompanying drawings, outlines an Ethernet fault recovery method for an in-vehicle remote communication terminal, a computer-readable storage medium, a vehicle, and an Ethernet fault recovery device for an in-vehicle remote communication terminal, all proposed in this application.

[0028] Figure 1 This is a flowchart of a method for recovering Ethernet faults in a vehicle-mounted remote communication terminal according to an embodiment of this application.

[0029] like Figure 1 As shown, the Ethernet fault recovery method for a vehicle-mounted remote communication terminal according to an embodiment of this application may include the following steps: S1, during the communication process of the vehicle-mounted remote communication terminal, if the connection status of the transmission control protocol is abnormal, the reachability of the central electronic module is obtained.

[0030] S2, when the central electronic module is reachable, determine the first target fault recovery strategy based on the reachability of the human-machine interaction terminal, the abnormality of the address resolution protocol cache table related to the human-machine interaction terminal, and the loss of multicast routes, and perform fault recovery based on the first target fault recovery strategy.

[0031] S3, when the central electronic module is in an unreachable state, determine the second target fault recovery strategy based on the abnormal situation of the address resolution protocol cache table related to the central electronic module, and perform fault recovery based on the second target fault recovery strategy.

[0032] Specifically, in one embodiment of this application, the vehicle-mounted remote communication terminal includes a hardware abstraction layer (HAL). The HAL provides a hardware operation interface; that is, the HAL in the vehicle-mounted remote communication terminal is an intermediate layer in the software architecture used to abstract hardware operations. Its function is to provide a unified interface for upper-layer software, facilitating interaction between the software and the underlying hardware, while shielding the differences between different hardware platforms. In other words, the HAL provides a unified hardware operation interface for different hardware platforms, allowing upper-layer software to operate without needing to concern itself with specific hardware details, supporting multiple hardware platforms, and improving software portability. For example, it can select automatic kernel loading or KO module loading of the driver program based on the hardware platform type, can uniformly map the power pin operations on the MCU / SOC side to control the power supply of the PHY chip, and can provide read and write operations on the PHY registers for obtaining or setting the physical layer state, etc. The HAL can provide a set of library functions for upper-layer software to call to perform hardware operations. Therefore, when hardware changes, only the HAL layer needs to be modified, without changing the upper-layer software. Through HAL, the vehicle-mounted remote communication terminal can achieve compatibility with different hardware platforms, simplifying software development and improving system stability and reliability.

[0033] TCP (Transmission Control Protocol) connection status refers to the connection status at the transport layer, which involves higher-level network communication protocols. The TCP connection status reflects the state of the TCP session between two devices. For example, the TCP connection established between a vehicle's TBox and a cloud platform allows for data exchange, such as vehicle status information and remote control commands. When the in-vehicle TBox communicates with the vehicle's internal systems, it may need to establish TCP connections with other electronic control units within the vehicle to collect vehicle data or send control commands. When the in-vehicle TBox communicates with other external services, it may also need to establish TCP connections with other external services (such as traffic information providers, emergency assistance services, etc.). For example, the TCP connection status can be queried through the network interface provided by the operating system. Alternatively, network monitoring tools can be used to view the TCP connection status. Therefore, by monitoring Ethernet and TCP connection status in real time, network connectivity problems can be quickly identified, responded to promptly, and the duration of failures can be reduced. Furthermore, through layered monitoring, the level at which the problem occurs can be accurately located, improving the targeting and efficiency of fault handling, and allowing for the determination of appropriate recovery strategies based on different problems.

[0034] The connection status of the Transmission Control Protocol (TCP) is assessed. If the TCP connection status is abnormal, the reachability of the Central Electronic Module (CEM) can be obtained. If the CEM is reachable, a first-target fault recovery strategy can be determined based on the reachability of the Human-Machine Interaction Terminal (HUT), anomalies in the Address Resolution Protocol (ARP) cache table associated with the HUT, and the loss of multicast routes. Fault recovery is then performed based on this first-target fault recovery strategy. For example, the reachability of the CEM can be checked by sending ping requests or other network probing methods. If the CEM is reachable, it indicates that the basic network connection is normal, and the problem may lie at a higher layer. A network probing request can also be sent to the HUT to check its reachability. This step is to determine whether the problem is limited to the HUT or the connection with the TBox. For example, if the HUT is reachable, it may indicate a problem at the application or service layer, requiring the restart of relevant services or modules. If the HUT is unreachable, the problem may lie at the network layer, requiring further diagnosis of network configuration or routing issues. Further diagnostics can be performed on network layer issues. For example, commands like `arp -n` can be used to check the Address Resolution Protocol (ARP) cache table related to the human-machine interface terminal to confirm the correct IP (Internet Protocol) to MAC (Media Access Control) address mapping, ensuring the network layer's address resolution function is working correctly—this is fundamental to network communication. Commands like `ip mrouteshow` can also be used to check if the vehicle communication module has established the necessary multicast routing table entries, ensuring multicast packets are correctly distributed to all subscribed devices.

[0035] Therefore, based on the reachability of the human-machine interface terminal, the anomalies in the address resolution protocol cache table related to the human-machine interface terminal, and the loss of multicast routes, a first-target fault recovery strategy can be determined through a pre-defined correspondence. For example, the relationship between the reachability of the human-machine interface terminal, the anomalies in the address resolution protocol cache table related to the human-machine interface terminal, the loss of multicast routes, and the first-target fault recovery strategy can be determined in advance. After the reachability of the human-machine interface terminal, the anomalies in the address resolution protocol cache table related to the human-machine interface terminal, and the loss of multicast routes are determined, the first-target fault recovery strategy can be obtained by directly calling the correspondence. Thus, fault recovery can be performed according to the determined first-target fault recovery strategy. For example, for application layer problems, the application service module can be restarted and the TCP connection re-established; for network layer problems, the network configuration can be checked and repaired, such as adding or modifying static routes and adjusting network parameters. By executing the determined recovery strategy, an attempt is made to restore the TCP connection, ensuring the continuity and reliability of data transmission.

[0036] The reachability of the Central Electronic Module (CEM) is determined. If the CEM is unreachable, a second-target fault recovery strategy can be determined based on anomalies in the Address Resolution Protocol (ARP) cache table associated with the CEM. Fault recovery is then performed based on this second-target strategy. In other words, the unreachability of the CEM indicates a potential network layer or lower-level problem. For example, sending a network probe request (such as a ping command) to the CEM can confirm its unreachability, thus determining if the problem lies at the network layer, particularly in the connection to the CEM. Next, the local ARP cache table is checked to confirm the correct IP-to-MAC address mapping, especially entries related to the CEM, ensuring that the address resolution function at the network layer is functioning correctly, which is fundamental to network communication.

[0037] Therefore, based on the anomalies in the Address Resolution Protocol (ARP) cache table related to the central electronic module (CEM), a second target fault recovery strategy can be determined through a pre-defined correspondence. For example, the relationship between the anomalies in the ARP cache table related to the CEM and the second target fault recovery strategy can be predetermined. Once the anomalies in the ARP cache table related to the CEM are determined, the second target fault recovery strategy can be obtained by directly invoking the correspondence. For instance, if the ARP table lacks entries related to CEM or the entries are incorrect, static ARP entries can be added or updated, and the CEM's IP address can be manually assigned to the correct MAC address to clear the incorrect ARP entries. Then, an attempt can be made to relearn the correct mapping. Thus, fault recovery can be performed according to the determined second target fault recovery strategy, such as executing corresponding network configurations or commands to restore network connectivity and ensure that data packets can be correctly sent to the CEM.

[0038] Therefore, by monitoring the TCP connection status and the reachability of the central electronic module in real time, network anomalies can be quickly identified and responded to in a timely manner, reducing communication interruptions caused by network problems. Furthermore, based on the reachability of the central electronic module and the human-machine interface terminal, as well as the status of the address resolution protocol cache table and multicast routing, the level at which the problem is located can be accurately pinpointed, and targeted recovery strategies can be executed, avoiding unnecessary complex operations and improving the success rate and efficiency of fault recovery. Moreover, through layered fault detection and recovery, various network anomalies can be handled more reliably, enhancing the stability and reliability of the entire vehicle network communication system.

[0039] According to one embodiment of this application, a first target fault recovery strategy is determined based on the reachability of the human-machine interaction terminal, the abnormality of the address resolution protocol cache table related to the human-machine interaction terminal, and the loss of multicast routes. This includes: when the human-machine interaction terminal is reachable and the address resolution protocol cache table related to the human-machine interaction terminal is abnormal, determining the first target fault recovery strategy as receiving static target address resolution protocol entries related to the human-machine interaction terminal; when the human-machine interaction terminal is unreachable and multicast routes are lost, determining the first target fault recovery strategy as receiving static multicast routes; and when the human-machine interaction terminal is unreachable and multicast routes are not lost, if monitoring the vehicle communication protocol reveals a multicast subscription failure event, then determining the first target fault recovery strategy as restarting the application layer service module.

[0040] Specifically, when determining the first target fault recovery strategy based on the reachability of the human-machine interaction terminal, the abnormality of the address resolution protocol cache table related to the human-machine interaction terminal, and the loss of multicast routes, the reachability of the human-machine interaction terminal is judged. If the human-machine interaction terminal is reachable, it is necessary to determine whether there is an abnormality in the address resolution protocol cache table related to the human-machine interaction terminal. If there is an abnormality in the address resolution protocol cache table, the first target fault recovery strategy can be determined to be to receive static target address resolution protocol entries related to the human-machine interaction terminal.

[0041] For example, determining whether a HUT is reachable can be done by sending a network probe request (such as a ping command) to the HUT. If the HUT responds to the ping request, it is considered reachable; otherwise, it is considered unreachable. If the HUT is reachable, the next step is to check the Address Resolution Protocol (ARP) cache table associated with the HUT for anomalies. The ARP cache table is a database used by the operating system to store IP address-to-MAC address mappings. The HUT's IP address is checked for a correct entry in the ARP table, such as using the `arp -n` command or similar tools to check the local ARP cache table and confirm the correct IP-to-MAC address mapping. If no entry is found in the ARP cache table corresponding to the HUT's IP address, or if the entry information is incorrect (e.g., an incorrect MAC address), an anomaly is considered. If an anomaly is found in the ARP cache table, a static ARP entry associated with the HUT is added, mapping the HUT's IP address to the correct MAC address. This static entry is not overwritten by the dynamic ARP process, thus ensuring that the HUT can be correctly identified and communicated with.

[0042] If the HUT is unreachable, it is determined whether a multicast route has been lost. If a multicast route is lost, the first-line fault recovery strategy is to receive a static multicast route. In other words, if the HUT is unreachable, a multicast route problem is checked. Multicast routes allow data packets to be sent to multiple destinations, which is used in vehicular networks for functions such as service discovery and event notification. If no correct multicast route is found to reach the HUT, it means the multicast route may have been lost. If a multicast route is lost, a static multicast route is added to ensure that data packets can be correctly distributed to the HUT.

[0043] Furthermore, if the reachability of the human-machine interface terminal is unreachable and the multicast route is not lost, the status of the vehicle communication protocol can be monitored to determine if a multicast subscription failure event exists. If a multicast subscription failure event is confirmed, the primary fault recovery strategy is to restart the application layer service module. In other words, if the multicast route is not lost, but a multicast subscription failure event is detected by monitoring the vehicle communication protocol (such as SOME / IP), this may indicate a problem at the application layer. The relevant application layer service module can be restarted to restore service discovery and multicast subscription functionality.

[0044] Therefore, by considering different levels of problems and corresponding recovery measures, and by quickly locating the level of the problem and implementing targeted recovery measures, the intelligent connected vehicle TBox can take the most appropriate and effective recovery measures when facing network communication problems.

[0045] According to one embodiment of this application, determining a second target fault recovery strategy based on an anomaly in the address resolution protocol cache table related to the central electronic module includes: if the address resolution protocol cache table related to the central electronic module is abnormal, determining the second target fault recovery strategy as receiving static target address resolution protocol entries related to the central electronic module; if the address resolution protocol cache table related to the central electronic module is normal and the number of times the second target fault recovery strategy is executed is less than a preset number, determining the second target fault recovery strategy as a first fault reset strategy. The preset number of times can be determined according to actual circumstances.

[0046] Specifically, when determining the second target fault recovery strategy based on the anomalies in the Address Resolution Protocol (ARP) cache table related to the central electronic module (CEM), the anomalies in the ARP cache table are assessed. This involves checking the ARP cache table to confirm that each IP address corresponds to the correct MAC address and to check for missing entries (i.e., some IP addresses lack corresponding MAC addresses) or incorrect entry information (e.g., incorrect MAC addresses). This ensures that the network layer can correctly resolve IP addresses to MAC addresses, which is fundamental to network communication. When an anomaly is detected in the ARP cache table, the second target fault recovery strategy is determined to be receiving static ARP entries related to the CEM. This involves manually adding static ARP entries to the ARP cache table, mapping the CEM's IP addresses to the correct MAC addresses. These static ARP entries are manually configured and will not change due to dynamic changes in network communication. By using static entries, it is ensured that even if the ARP cache table has problems, data packets can still be correctly sent to the CEM. Therefore, by receiving static ARP entries, the ARP cache table anomaly problem can be effectively resolved, ensuring that the communication of critical equipment (such as the CEM) is not affected.

[0047] Anomalies in the Address Resolution Protocol (ARP) cache table related to the central electronic module are assessed. If the ARP cache table is normal and the number of times the second target fault recovery strategy has been executed is less than the preset number, it indicates that all ARP entries are correct, without missing or incorrect entries. Furthermore, the fact that the number of times the target fault recovery strategy has been executed is less than the preset number means that the number of fault recovery attempts has not yet reached the preset number (e.g., 3 times). Therefore, the second target fault recovery strategy can be determined as the first fault reset strategy. This reset operation further diagnoses and resolves more complex problems that may be causing ARP cache table anomalies. Limiting the number of recovery operations prevents excessive system intervention, which could cause unnecessary interference to the normally operating network. Frequent fault recovery operations can consume significant system resources, such as CPU time, memory, and network bandwidth. Limiting the number of operations allows for more effective management of these resources.

[0048] Therefore, it can promptly detect and respond to ARP cache table anomalies, quickly attempt to restore network connectivity, execute corresponding network diagnostics and recovery operations according to the determined first fault recovery strategy, resolve the root causes that may lead to ARP cache table anomalies, restore normal network function, consider different levels of problems and corresponding recovery measures, and ensure that the intelligent connected vehicle TBox can take the most appropriate and effective recovery measures when facing network communication problems.

[0049] According to one embodiment of this application, a first fault reset strategy includes: when a first target reset duration is reached, sending a reset command to the target register of the physical layer chip and obtaining the Ethernet connection status after sending the reset command, wherein the reset command is used to trigger the reset of the physical layer chip to restore the target register to its initial state; when the connection status is an Ethernet disconnected state or an unknown Ethernet connection status, powering off and restarting the physical layer chip based on a target operation, wherein the target operation includes controlling the power supply pins of the physical layer chip based on a microcontroller or system-on-a-chip; after powering off and restarting the physical layer chip and the connection status is an Ethernet disconnected state or an unknown Ethernet connection status, unloading and reloading the driver program corresponding to the physical layer chip. The second target reset duration can be determined according to actual conditions.

[0050] Specifically, the hardware adaptation layer maps the target operation of the power pins through the hardware operation interface. That is, the hardware adaptation layer can identify the type of the current hardware platform (such as MCU or SOC) and map the corresponding power pins. These power pins control the power supply of the physical layer chip in order to prepare for the subsequent power-off and restart operation and ensure that the power supply of the physical layer chip can be correctly controlled.

[0051] The system determines whether the first target reset duration has been reached. If so, a reset command is sent to the target register of the physical layer chip, and the Ethernet connection status after sending the reset command is obtained. The reset command triggers the physical layer chip to reset, restoring the target register to its initial state. The first target reset duration refers to the length of time the system waits before attempting to restore the connection, ensuring sufficient time for potential temporary problems to resolve themselves before executing the reset operation. Upon detecting an abnormal Ethernet connection status (DOWN or UNKNOWN), a reset operation is not performed immediately; instead, a preset first target reset duration is waited for. This duration can be set during system design based on experience or test results to avoid excessively frequent reset operations and reduce system interference. The reset command is an instruction used to trigger the PHY chip reset, implemented by writing software into a specific register of the PHY. Once the first target reset duration is reached, a reset command is sent to the control register of the PHY chip through the HAL layer. This command triggers the reset logic within the PHY chip, restoring the chip's status register to its initial state.

[0052] After sending the reset command, the effect of the reset operation needs to be verified. This can be done by reading the PHY's status register again through the HAL layer to obtain the Ethernet connection status. If the connection status changes to UP, it indicates that the reset was successful and the network connection has been restored. If the connection status remains DOWN or UNKNOWN, a preset strategy will determine whether further operation is needed, such as a hard reset. That is, when the connection status is Ethernet disconnected or unknown, the physical layer chip is powered off and restarted through a target operation. The target operation includes controlling the power pins of the physical layer chip through a microcontroller or system-on-a-chip. In other words, if a soft reset fails to restore the connection, a hard reset will be performed, i.e., powering off and restarting the PHY chip. For example, by controlling the PHY chip's power pins through an MCU or SOC, the power is first cut off and then restored. This process forces the PHY chip to perform a complete reset, clearing all status information and reinitializing.

[0053] After powering off and restarting the physical layer chip, the PHY status register can be read again to obtain the Ethernet connection status, confirming whether the restart was successful and whether the link has been restored. If the connection status remains Ethernet disconnected or unknown after powering off and restarting, the corresponding driver for the physical layer chip can be uninstalled and reloaded to clear possible driver errors or resource leaks, and communication with the PHY chip can be restored by reloading the driver.

[0054] Therefore, by gradually increasing the intensity of operations from the software to the hardware level, problems at different levels can be solved. Furthermore, by limiting the number of power outages and restarts, unnecessary wear and tear on the PHY chip can be reduced, frequent hardware operations can be avoided, and the stability of the entire network communication system can be improved.

[0055] According to one embodiment of this application, the Ethernet fault recovery method for a vehicle-mounted remote communication terminal further includes: acquiring the Ethernet connection status, wherein the Ethernet connection status includes an Ethernet disconnected state and an unknown Ethernet connection status; when the Ethernet connection status is an unknown Ethernet connection status, performing fault recovery based on a third target fault recovery strategy, wherein the third target fault recovery strategy is to periodically execute a second fault reset strategy; when the Ethernet connection status is an Ethernet disconnected state, acquiring the cable status of the Ethernet cable, and when the cable status is normal, performing fault recovery based on a fourth target fault recovery strategy, wherein the fourth target fault recovery strategy is to execute the second fault reset strategy once.

[0056] Specifically, during the communication process of the vehicle-mounted remote communication terminal, the Ethernet connection status can also be acquired. This Ethernet connection status includes Ethernet disconnection and unknown Ethernet connection status. Monitoring and acquiring the Ethernet connection status is a crucial step in ensuring the reliability and stability of network communication. The Ethernet connection status refers to the status of the physical layer and data link layer, which is typically managed by the physical layer chip. The main Ethernet connection statuses include: UP (normal Ethernet connection, indicating that the physical link has been established and data transmission can occur), DOWN (Ethernet disconnection, indicating that the physical link has not been established and data transmission cannot occur), and UNKNOWN (unknown Ethernet connection status, indicating that the PHY chip cannot determine the link status, possibly due to hardware failure or other underlying issues). For example, the status registers of the PHY chip, containing Ethernet connection status information, can be periodically read through the interface provided by the Hardware Adaptor Layer (HAL).

[0057] The Ethernet connection status is assessed. In cases where the Ethernet connection status is unknown, fault recovery is performed based on a third-target fault recovery strategy, which involves periodically executing a second fault reset strategy. In other words, an unknown Ethernet connection status typically indicates an anomaly at the physical layer, but the specific cause is unclear. In such situations, a fault recovery strategy is needed to attempt to restore the network connection. This means that the second fault reset strategy is automatically executed within a preset period (e.g., at regular intervals or under specific conditions), rather than only once when an anomaly is detected. This periodic execution helps to continuously attempt to restore the connection as the problem persists, rather than giving up after a single attempt. For example, a soft reset operation can be performed periodically. This is a method of resetting the logic of the PHY chip through software commands. Soft reset is a non-destructive operation that does not cause physical damage to the hardware and is suitable for frequent execution. A soft reset operation involves writing a specific reset command to the PHY register, which can be done directly or through the operating system's network management interface. After the reset is complete, the PHY status register is checked again to confirm that the connection status has been restored. Therefore, periodically executing the soft reset strategy can quickly respond to unknown connection states and attempt to restore network connectivity as soon as possible. By periodically executing this second fault reset strategy, the vehicle-mounted remote communication terminal can take effective recovery measures when facing uncertain network connection problems, thereby improving the stability and reliability of the entire network system and reducing communication interruptions caused by connection problems.

[0058] The connection status of the Ethernet network is determined. If the Ethernet connection is down, the cable status of the Ethernet cable can be obtained. For example, the cable status can be obtained through the hardware operation interface of the hardware adapter layer. In other words, when the Ethernet connection status shows as DOWN, this usually means that the physical link has not been established, which could be due to various reasons such as cable problems, non-response from the peer device, or configuration errors. In this case, the cable status of the Ethernet cable is obtained through the hardware operation interface. For example, the cable status obtained through the hardware operation interface can include Normal (cable connection is normal, no physical damage), Open (cable disconnected, possibly due to the cable being pulled out or broken), and Short (cable short circuit, possibly due to internal short circuit in the cable or external object). The current cable status is then determined. If the cable status is normal, fault recovery can be performed based on the fourth target fault recovery strategy, where the fourth target fault recovery strategy is a single execution of the second fault reset strategy.

[0059] In other words, if the cable status is normal, the problem may not be with the physical cable connection, but rather due to software configuration errors, issues with the peer device, or temporary communication problems. In this case, a second fault reset strategy is executed, such as a single soft reset, which resets the PHY chip once via software commands to attempt to restore the link. That is, a normal cable status means there is no physical connection problem; the issue may lie in software configuration, the peer device, or temporary communication problems. A single reset can serve as an initial recovery attempt to resolve potential temporary or minor faults. If the problem is caused by temporary network fluctuations or configuration errors, a single reset is likely to resolve the issue without multiple attempts, thus improving fault recovery efficiency, quickly restoring service, and reducing waiting time.

[0060] In another embodiment of this application, if the cable is in an abnormal state, such as being open or short-circuited, the software will not perform any processing. Instead, detailed information about the cable abnormality, including timestamps and cable status, will be recorded in the system log. An alarm message can be issued to prompt relevant personnel to inspect the cable, such as checking for visible physical damage, such as breakage, flattening, or wear. If a loose connection or poor contact is found, the cable should be re-plugged and re-plugged to ensure a secure connection. If the cable has physical damage, such as breakage or severe wear, it should be replaced with a new cable.

[0061] Therefore, by monitoring the Ethernet connection status in real time and determining the corresponding recovery strategy based on the connection status, the vehicle-mounted remote communication terminal can quickly detect and respond to connection anomalies when faced with Ethernet communication problems, and execute targeted recovery measures. This avoids blind recovery operations, reduces fault recovery time, and thus improves the stability and reliability of the vehicle's internal network, as well as the success rate and efficiency of fault recovery.

[0062] According to one embodiment of this application, a second fault reset strategy includes: when a second target reset duration is reached, sending a reset command to the target register of the physical layer chip and obtaining the Ethernet connection status after sending the reset command, wherein the reset command is used to trigger a reset of the physical layer chip to restore the target register to its initial state; when the connection status is an Ethernet disconnected state or an unknown Ethernet connection status, powering off and restarting the physical layer chip through a target operation, wherein the target operation includes controlling the power supply pins of the physical layer chip through a microcontroller or system-on-a-chip. The second target reset duration can be determined according to actual conditions.

[0063] Specifically, the hardware adaptation layer can map power pins through its hardware operation interface to execute the first fault reset strategy. This is a reset operation for the physical layer chip, designed to restore Ethernet connectivity. The hardware adaptation layer initializes during system startup, identifies the current hardware platform type, and configures the corresponding hardware operation interface. The HAL layer maps power pins on the MCU or SOC side according to the hardware platform type to control the power supply of the PHY chip. Through the hardware operation interface provided by the HAL layer, it periodically reads the PHY register to determine the Ethernet connection status (UP, DOWN, UNKNOWN). When the Ethernet connection status is detected as DOWN or UNKNOWN, the HAL layer executes the second fault reset strategy.

[0064] The system determines whether the second target reset duration has been reached. If so, a reset command is sent to the target register of the physical layer chip, and the Ethernet connection status after sending the reset command is obtained. The reset command triggers the physical layer chip to reset the target register, restoring it to its initial state. The second target reset duration refers to the length of time the system waits before attempting to restore the connection, ensuring sufficient time for potential temporary problems to resolve themselves before performing a reset operation. Upon detecting an abnormal Ethernet connection status (DOWN or UNKNOWN), a reset operation is not performed immediately; instead, a preset second target reset duration is waited for. This duration can be set during system design based on experience or test results to avoid excessively frequent reset operations and reduce system interference. The reset command is an instruction used to trigger the PHY chip reset, implemented by writing software into a specific register of the PHY. Once the second target reset duration is reached, a reset command is sent to the control register of the PHY chip through the HAL layer. This command triggers the reset logic within the PHY chip, restoring the chip's status register to its initial state.

[0065] After sending the reset command, the effect of the reset operation needs to be verified. This can be done by reading the PHY's status register again through the HAL layer to obtain the Ethernet connection status. If the connection status changes to UP, it indicates that the reset was successful and the network connection has been restored. If the connection status remains DOWN or UNKNOWN, a further operation, such as a hard reset, can be performed according to a preset strategy. This means that when the connection status is Ethernet disconnected or unknown, the physical layer chip is powered off and restarted through a target operation. This target operation includes controlling the power pins of the physical layer chip through a microcontroller or system-on-a-chip. In other words, if a soft reset fails to restore the connection, a hard reset will be performed, i.e., powering off and restarting the PHY chip. For example, by controlling the PHY chip's power pins through an MCU or SOC, the power is first cut off and then restored. This process forces the PHY chip to undergo a complete reset, clearing all status information and reinitializing.

[0066] Therefore, the PHY reset strategy, triggered by a PHY connection anomaly, is a physical layer issue. Thus, a PHY soft reset is performed first. A soft reset resets the chip logic via the PHY registers, is quick (ms-level), and does not affect the physical connection, making it suitable for temporary register errors. If this fails, a PHY hard reset is then performed. A hard reset controls the MCU or SOC power pin to power off and restart the PHY, resolving hardware deadlocks or power supply anomalies, and takes about 100ms. This reset sequence, from minor to major operations, avoids premature hardware resets that could lead to system instability. If the soft reset is successful, no hardware operation is needed, extending the PHY's lifespan. In other words, by attempting a soft reset first and only performing a hard reset when necessary, unnecessary hardware wear is reduced. By attempting recovery at different levels, the problem is ensured to be resolved at the earliest possible stage.

[0067] According to one embodiment of this application, the Ethernet fault recovery method for a vehicle-mounted remote communication terminal further includes: obtaining the sum of the number of Ethernet connection failures after sending a reset command and after power-off restarting the physical layer chip; determining a target preset duration based on the sum of the number of failures and a preset mapping relationship, wherein the preset mapping relationship is used to indicate the relationship between the sum of the number of failures and the target preset duration; updating a second target reset duration based on the target preset duration to reduce the frequency of periodically executing the second fault reset strategy.

[0068] Specifically, in one embodiment of this application, in addition to performing fault detection and basic reset strategies, a mechanism for dynamically adjusting the reset frequency is also included. The sum of the number of Ethernet connection failures after sending a reset command and after a power-off restart of the physical layer chip can be obtained. That is, after each reset attempt (whether a soft reset or a hard reset), the number of Ethernet connection failures can be recorded. These counts can represent the number of unsuccessful attempts by the system to restore the connection. By recording the number of failures, the severity of the problem and the strength of the recovery measures that may need to be taken can be assessed. After obtaining the sum of the counts, a target preset duration can be determined based on the sum of the counts and a preset mapping relationship. That is, a preset mapping relationship is pre-designed, which defines the relationship between the number of failures and the target preset duration. For example, when the number of failures is low, the preset duration may be short to facilitate rapid recovery attempts; when the number of failures is high, the preset duration may be long to avoid frequent reset operations. Based on the recorded number of failures, the system searches the preset mapping relationship to determine the target preset duration. Thus, by dynamically adjusting the time interval of reset attempts, the use of system resources is optimized, and unnecessary hardware operations are reduced. After determining the target preset duration, the second target reset duration can be updated based on the target preset duration to reduce the frequency of periodically executing the second fault reset strategy. That is, based on the determined target preset duration, the time of the next reset attempt is updated. This duration is used to control the time of the next execution of the second fault reset strategy. By reducing the frequency of periodically executing the second fault reset strategy, the impact on system stability is reduced, while extending the hardware lifespan.

[0069] For example, suppose the vehicle-mounted remote communication terminal system initially resets after startup with a preset initial reset period of 30 seconds. If the Ethernet connection status is detected as DOWN or UNKNOWN, a soft reset (first priority) is performed first. If the soft reset fails, the failure count is recorded as 1. Then, a hard reset (second priority) is attempted. If the hard reset fails, the failure count is recorded as 2. Based on the number of failures (2), the reset period is adjusted to 60 seconds. After 60 seconds, a soft reset is attempted first. If the soft reset fails, the failure count is recorded as 3. Then, a hard reset is attempted. If the hard reset fails, the failure count is recorded as 4. Based on the number of failures (4), the reset period is adjusted to 90 seconds. After 90 seconds, a soft reset is attempted first. If the soft reset fails, the failure count is recorded as 5. Then, a hard reset is attempted. If the hard reset succeeds, the failure count is reset to 0, and the initial reset period of 30 seconds is restored.

[0070] Therefore, by gradually increasing the reset cycle, unnecessary reset operations on the PHY chip are reduced, hardware wear is reduced, thereby extending hardware lifespan. Furthermore, system instability caused by frequent reset operations is avoided, and system stability is improved by reducing the reset frequency.

[0071] The following is combined Figure 2 The method described in this application is used to describe the method.

[0072] As a specific example, the Ethernet fault recovery method for the vehicle-mounted remote communication terminal of this application may include the following steps: S101, during the communication process of the vehicle-mounted remote communication terminal, the connection status of the Ethernet and the connection status of the transmission control protocol are obtained, and then the process proceeds to steps S102 and S109 respectively.

[0073] S102, determine whether the Ethernet connection status is unknown. If yes, proceed to step S103; if no, proceed to step S104.

[0074] S103, perform fault recovery based on the third target fault recovery strategy, wherein the third target fault recovery strategy is to periodically execute the second fault reset strategy.

[0075] S104. Determine whether the Ethernet connection status is Ethernet disconnected. If yes, proceed to step S105; otherwise, proceed to step S101.

[0076] S105, obtain the cable status of the Ethernet cable.

[0077] S106. Determine if the cable status is normal. If yes, proceed to step S107; otherwise, proceed to step S108.

[0078] S107, perform fault recovery based on the fourth target fault recovery strategy, wherein the fourth target fault recovery strategy is to execute the second fault reset strategy once.

[0079] S108 issues a cable fault alarm message, but no software processing is performed.

[0080] S109, Determine whether the connection status of the Transmission Control Protocol is abnormal. If yes, proceed to step S110; if no, proceed to step S101.

[0081] S110, obtain the accessibility of the central electronic module.

[0082] S111, determine whether the central electronic module is reachable. If yes, proceed to step S112; otherwise, proceed to step S115.

[0083] S112, obtain the accessibility of the human-computer interaction terminal.

[0084] S113, determine whether the reachability of the human-computer interaction terminal is in a reachable state. If yes, proceed to step S114; if no, proceed to step S115.

[0085] S114, determine whether there is an anomaly in the address resolution protocol cache table, so that if there is an anomaly in the address resolution protocol cache table, determine the target fault recovery strategy as receiving static target address resolution protocol entries related to the human-machine interaction terminal.

[0086] S115, determine whether the multicast route is lost. If the multicast route is lost, determine the target fault recovery strategy as receiving static multicast routes. If the multicast route is not lost and the status is found to be a multicast subscription failure event through monitoring the vehicle communication protocol, determine the target fault recovery strategy as restarting the application layer service module.

[0087] S116, determine whether there is an anomaly in the address resolution protocol cache table. If there is an anomaly in the address resolution protocol cache table, determine the target fault recovery strategy as receiving static target address resolution protocol entries related to the central electronic module. If the address resolution protocol cache table is normal and the number of times the target fault recovery strategy is executed is less than the preset number, determine the target fault recovery strategy as the first fault reset strategy, including soft reset, hard reset and drive reset, and perform recovery based on the first fault reset strategy.

[0088] In summary, the Ethernet fault recovery method for a vehicle-mounted remote communication terminal according to the embodiments of this application, during the communication process of the vehicle-mounted remote communication terminal, if the connection status of the transmission control protocol is abnormal, the reachability of the central electronic module is obtained. If the central electronic module is reachable, a first target fault recovery strategy is determined based on the reachability of the human-machine interface terminal, the abnormality of the address resolution protocol cache table related to the human-machine interface terminal, and the loss of multicast routes. Fault recovery is performed based on the first target fault recovery strategy. If the central electronic module is unreachable, a second target fault recovery strategy is determined based on the abnormality of the address resolution protocol cache table related to the central electronic module. Fault recovery is performed based on the second target fault recovery strategy. Therefore, this method can quickly and accurately locate the level of the problem and execute targeted recovery measures, avoiding blind recovery operations and improving the efficiency and success rate of fault recovery.

[0089] Corresponding to the above embodiments, this application also proposes a computer-readable storage medium.

[0090] The computer-readable storage medium of this application embodiment stores a program that, when executed by a processor, implements the above-described method for Ethernet fault recovery of a vehicle-mounted remote communication terminal.

[0091] According to the computer-readable storage medium of the embodiments of this application, by executing the above-described vehicle-mounted remote communication terminal Ethernet fault recovery method, the level at which the problem is located can be quickly and accurately located, and targeted recovery measures can be performed, avoiding blind recovery operations and improving the efficiency and success rate of fault recovery.

[0092] Corresponding to the above embodiments, this application also proposes a vehicle.

[0093] like Figure 3 As shown, the vehicle 200 in this embodiment may include: a memory 210, a processor 220, and a program stored in the memory 210 and executable on the processor 220. When the processor 220 executes the program, it implements the above-mentioned vehicle-mounted remote communication terminal Ethernet fault recovery method.

[0094] According to the embodiments of this application, by executing the above-described vehicle-mounted remote communication terminal Ethernet fault recovery method, the vehicle can quickly and accurately locate the level of the problem and execute targeted recovery measures, avoiding blind recovery operations and improving the efficiency and success rate of fault recovery.

[0095] Corresponding to the above embodiments, this application also proposes an Ethernet fault recovery device for vehicle-mounted remote communication terminals.

[0096] like Figure 4 As shown, the vehicle-mounted remote communication terminal Ethernet fault recovery device 100 of this application embodiment includes: an acquisition module 110, a first fault recovery module 120, and a second fault recovery module 130.

[0097] The acquisition module 110 is used to acquire the reachability of the central electronic module if the connection status of the transmission control protocol is abnormal during the communication process of the vehicle-mounted remote communication terminal. The first fault recovery module 120 is used to determine a first target fault recovery strategy based on the reachability of the human-machine interaction terminal, the abnormality of the address resolution protocol cache table related to the human-machine interaction terminal, and the loss of multicast routes when the central electronic module is reachable, so as to perform fault recovery based on the first target fault recovery strategy. The second fault recovery module 130 is used to determine a second target fault recovery strategy based on the abnormality of the address resolution protocol cache table related to the central electronic module when the central electronic module is unreachable, so as to perform fault recovery based on the second target fault recovery strategy.

[0098] According to one embodiment of this application, the first fault recovery module 120 determines a first target fault recovery strategy based on the reachability of the human-machine interaction terminal, the abnormality of the address resolution protocol cache table related to the human-machine interaction terminal, and the loss of multicast routes. Specifically, it is used to: when the reachability of the human-machine interaction terminal is reachable and the address resolution protocol cache table related to the human-machine interaction terminal is abnormal, determine the first target fault recovery strategy as receiving static target address resolution protocol entries related to the human-machine interaction terminal; when the reachability of the human-machine interaction terminal is unreachable and the multicast route is lost, determine the first target fault recovery strategy as receiving static multicast routes; when the reachability of the human-machine interaction terminal is unreachable and the multicast route is not lost, if monitoring the vehicle communication protocol reveals a multicast subscription failure event, determine the first target fault recovery strategy as restarting the application layer service module.

[0099] According to one embodiment of this application, the second fault recovery module 130 determines a second target fault recovery strategy based on the abnormality of the address resolution protocol cache table related to the central electronic module, including: when there is an abnormality in the address resolution protocol cache table related to the central electronic module, determining the second target fault recovery strategy as receiving static target address resolution protocol entries related to the central electronic module; when the address resolution protocol cache table related to the central electronic module is normal and the number of times the second target fault recovery strategy is executed is less than a preset number, determining the second target fault recovery strategy as a first fault reset strategy.

[0100] According to one embodiment of this application, a first fault reset strategy includes: when a first target reset duration is reached, sending a reset instruction to the target register of the physical layer chip and obtaining the Ethernet connection status after sending the reset instruction, wherein the reset instruction is used to trigger the reset of the physical layer chip to restore the target register to its initial state; when the connection status is an Ethernet disconnected state or an unknown Ethernet connection status, powering off and restarting the physical layer chip based on a target operation, wherein the target operation includes controlling the power supply pins of the physical layer chip based on a microcontroller or system-on-a-chip; and after powering off and restarting the physical layer chip and when the connection status is an Ethernet disconnected state or an unknown Ethernet connection status, unloading and reloading the driver program corresponding to the physical layer chip.

[0101] According to one embodiment of this application, the acquisition module 110 is further configured to: acquire the connection status of the Ethernet, wherein the connection status of the Ethernet includes an Ethernet disconnected state and an unknown Ethernet connection status; when the Ethernet connection status is an unknown Ethernet connection status, perform fault recovery based on a third target fault recovery strategy, wherein the third target fault recovery strategy is to periodically execute a second fault reset strategy; when the Ethernet connection status is an Ethernet disconnected state, acquire the cable status of the Ethernet cable, and when the cable status is normal, perform fault recovery based on a fourth target fault recovery strategy, wherein the fourth target fault recovery strategy is to execute the second fault reset strategy once.

[0102] According to one embodiment of this application, a second fault reset strategy includes: when a second target reset duration is reached, sending a reset instruction to the target register of the physical layer chip and obtaining the Ethernet connection status after sending the reset instruction, wherein the reset instruction is used to trigger the reset of the physical layer chip to restore the target register to its initial state; when the connection status is an Ethernet disconnected state or an unknown Ethernet connection status, powering off and restarting the physical layer chip through a target operation, wherein the target operation includes controlling the power supply pins of the physical layer chip through a microcontroller or system-on-a-chip.

[0103] According to one embodiment of this application, the acquisition module 110 is further configured to: acquire the sum of the number of Ethernet connection failures after sending a reset command and after power-off restart of the physical layer chip; determine a target preset duration based on the sum of the number of failures and a preset mapping relationship, wherein the preset mapping relationship is used to indicate the relationship between the sum of the number of failures and the target preset duration; update the second target reset duration based on the target preset duration to reduce the frequency of periodically executing the second fault reset strategy.

[0104] It should be noted that for details not disclosed in the vehicle-mounted remote communication terminal Ethernet fault recovery method of this application embodiment, please refer to the details disclosed in the vehicle-mounted remote communication terminal Ethernet fault recovery device of this application embodiment, which will not be repeated here.

[0105] According to the vehicle-mounted remote communication terminal Ethernet fault recovery device of this application embodiment, the acquisition module is used to acquire the reachability of the central electronic module if the connection status of the transmission control protocol is abnormal during the communication process of the vehicle-mounted remote communication terminal. The first fault recovery module is used to determine a first target fault recovery strategy based on the reachability of the human-machine interface terminal, the abnormality of the address resolution protocol cache table related to the human-machine interface terminal, and the loss of multicast routes when the central electronic module is reachable, and to perform fault recovery based on the first target fault recovery strategy. The second fault recovery module is used to determine a second target fault recovery strategy based on the abnormality of the address resolution protocol cache table related to the central electronic module when the central electronic module is unreachable, and to perform fault recovery based on the second target fault recovery strategy. Therefore, this device can quickly and accurately locate the level of the problem and execute targeted recovery measures, avoiding blind recovery operations and improving the efficiency and success rate of fault recovery.

[0106] It should be noted that the logic and / or steps represented in the flowchart or otherwise described herein, for example, can be considered as a sequenced list of executable instructions for implementing logical functions, and can be specifically implemented in any computer-readable medium for use by, or in conjunction with, an instruction execution system, apparatus, or device (such as a computer-based system, a processor-included system, or other system that can fetch and execute instructions from, an instruction execution system, apparatus, or device). For the purposes of this specification, "computer-readable medium" can be any means that can contain, store, communicate, propagate, or transmit programs for use by, or in conjunction with, an instruction execution system, apparatus, or device. More specific examples (a non-exhaustive list) of computer-readable media include: an electrical connection having one or more wires (electronic device), a portable computer disk drive (magnetic device), random access memory (RAM), read-only memory (ROM), erasable and editable read-only memory (EPROM or flash memory), fiber optic devices, and portable optical disc read-only memory (CDROM). Alternatively, the computer-readable medium may be paper or other suitable media on which the program can be printed, since the program can be obtained electronically, for example, by optically scanning the paper or other medium, followed by editing, interpreting, or otherwise processing as necessary, and then stored in a computer memory.

[0107] It should be understood that various parts of this application can be implemented using hardware, software, firmware, or a combination thereof. In the above embodiments, multiple steps or methods can be implemented using software or firmware stored in memory and executed by a suitable instruction execution system. For example, if implemented in hardware, as in another embodiment, it can be implemented using any one or a combination of the following techniques known in the art: discrete logic circuits having logic gates for implementing logical functions on data signals, application-specific integrated circuits (ASICs) having suitable combinational logic gates, programmable gate arrays (PGAs), field-programmable gate arrays (FPGAs), etc.

[0108] In the description of this specification, the references to terms such as "one embodiment," "some embodiments," "example," "specific example," or "some examples," etc., indicate that a specific feature, structure, material, or characteristic described in connection with that embodiment or example is included in at least one embodiment or example of this application. In this specification, the illustrative expressions of the above terms do not necessarily refer to the same embodiment or example. Furthermore, the specific features, structures, materials, or characteristics described may be combined in any suitable manner in one or more embodiments or examples.

[0109] Furthermore, the terms "first" and "second" are used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the number of technical features indicated. Thus, a feature defined as "first" or "second" may explicitly or implicitly include at least one of that feature. In the description of this application, "multiple" means at least two, such as two, three, etc., unless otherwise explicitly specified.

[0110] In this application, unless otherwise expressly specified and limited, the terms "installation," "connection," "joining," and "fixing," etc., should be interpreted broadly. For example, they can refer to a fixed connection, a detachable connection, or an integral part; they can refer to a mechanical connection or an electrical connection; they can refer to a direct connection or an indirect connection through an intermediate medium; they can refer to the internal communication of two components or the interaction between two components, unless otherwise expressly limited. Those skilled in the art can understand the specific meaning of the above terms in this application according to the specific circumstances.

[0111] Although embodiments of this application have been shown and described above, it is understood that the above embodiments are exemplary and should not be construed as limiting this application. Those skilled in the art can make changes, modifications, substitutions and variations to the above embodiments within the scope of this application.

Claims

1. A method for recovering from Ethernet faults in a vehicle-mounted remote communication terminal, characterized in that, The method includes: During the communication process of the vehicle-mounted remote communication terminal, if the connection status of the transmission control protocol is abnormal, the reachability of the central electronic module is obtained. When the central electronic module is reachable, a first target fault recovery strategy is determined based on the reachability of the human-computer interaction terminal, the abnormality of the address resolution protocol cache table related to the human-computer interaction terminal, and the loss of multicast routes, so as to perform fault recovery based on the first target fault recovery strategy. When the central electronic module is in an unreachable state, a second target fault recovery strategy is determined based on the abnormal situation of the address resolution protocol cache table associated with the central electronic module, and fault recovery is performed based on the second target fault recovery strategy.

2. The method for recovering Ethernet faults in a vehicle-mounted remote communication terminal according to claim 1, characterized in that, The determination of the first target fault recovery strategy based on the reachability of the human-computer interaction terminal, the abnormality of the address resolution protocol cache table related to the human-computer interaction terminal, and the loss of multicast routes includes: If the reachability of the human-computer interaction terminal is in a reachable state and the address resolution protocol cache table associated with the human-computer interaction terminal is abnormal, the first target fault recovery strategy is determined to be to receive static target address resolution protocol entries associated with the human-computer interaction terminal. If the reachability of the human-computer interaction terminal is unreachable and the multicast route is lost, the first target fault recovery strategy is determined to be receiving static multicast routes. If the reachability of the human-machine interaction terminal is unreachable and the multicast route is not lost, and if monitoring the vehicle communication protocol reveals a multicast subscription failure event, then the first target fault recovery strategy is determined to be restarting the application layer service module.

3. The method for recovering Ethernet faults in a vehicle-mounted remote communication terminal according to claim 1, characterized in that, The determination of the second target fault recovery strategy based on the abnormal situation of the address resolution protocol cache table related to the central electronic module includes: In the event of an anomaly in the address resolution protocol cache table associated with the central electronic module, the second target fault recovery strategy is determined to be to receive static target address resolution protocol entries associated with the central electronic module. If the address resolution protocol cache table associated with the central electronic module is normal and the number of times the second target fault recovery strategy is executed is less than the preset number, the second target fault recovery strategy is determined to be the first fault reset strategy.

4. The method for recovering Ethernet faults in a vehicle-mounted remote communication terminal according to claim 3, characterized in that, The first fault reset strategy includes: If the first target reset duration is reached, a reset instruction is sent to the target register of the physical layer chip, and the connection status of the Ethernet is obtained after the reset instruction is sent. The reset instruction is used to trigger the reset of the physical layer chip to restore the target register to its initial state. In the case where the connection status is Ethernet disconnected or unknown Ethernet connection status, the physical layer chip is powered off and restarted based on the target operation, wherein the target operation includes controlling the power pins of the physical layer chip based on a microcontroller or system-on-a-chip. If the physical layer chip is powered off and restarted and the connection status is either Ethernet disconnected or unknown Ethernet connected, the driver corresponding to the physical layer chip is uninstalled and reloaded.

5. The method for recovering Ethernet faults in a vehicle-mounted remote communication terminal according to claim 1, characterized in that, The method further includes: Obtain the Ethernet connection status, wherein the Ethernet connection status includes Ethernet disconnected status and unknown Ethernet connection status; When the Ethernet connection state is the unknown Ethernet connection state, fault recovery is performed based on the third target fault recovery strategy, wherein the third target fault recovery strategy is to periodically execute the second fault reset strategy. When the Ethernet connection status is the Ethernet disconnected status, the cable status of the Ethernet cable is obtained, and when the cable status is normal, fault recovery is performed based on the fourth target fault recovery strategy, wherein the fourth target fault recovery strategy is to execute the second fault reset strategy once.

6. The method for recovering Ethernet faults in a vehicle-mounted remote communication terminal according to claim 5, characterized in that, The second fault reset strategy includes: If the second target reset duration is reached, a reset instruction is sent to the target register of the physical layer chip, and the connection status of the Ethernet is obtained after the reset instruction is sent. The reset instruction is used to trigger the reset of the physical layer chip to restore the target register to its initial state. When the connection status is either the Ethernet disconnected state or the unknown Ethernet connection state, the physical layer chip is powered off and restarted through the target operation, wherein the target operation includes controlling the power pins of the physical layer chip through a microcontroller or system-on-a-chip.

7. The method for recovering Ethernet faults in a vehicle-mounted remote communication terminal according to claim 6, characterized in that, The method further includes: The sum of the number of Ethernet connection failures after sending the reset command and after power-off restart of the physical layer chip is obtained; The target preset duration is determined based on the sum of the number of times and the preset mapping relationship, wherein the preset mapping relationship is used to indicate the relationship between the sum of the number of times and the target preset duration; The second target reset duration is updated based on the target preset duration to reduce the frequency of periodically executing the second fault reset strategy.

8. A computer-readable storage medium, characterized in that, It stores a program that, when executed by a processor, implements the Ethernet fault recovery method for an in-vehicle remote communication terminal according to any one of claims 1-7.

9. A vehicle, characterized in that, include: The system includes a memory, a processor, and a program stored in the memory and executable on the processor, wherein when the processor executes the program, it implements the Ethernet fault recovery method for a vehicle-mounted remote communication terminal according to any one of claims 1-7.

10. A vehicle-mounted remote communication terminal Ethernet fault recovery device, characterized in that, The device includes: The acquisition module is used to acquire the reachability of the central electronic module if the connection status of the transmission control protocol is abnormal during the communication process of the vehicle-mounted remote communication terminal. The first fault recovery module is used to determine a first target fault recovery strategy based on the reachability of the human-machine interaction terminal, the abnormality of the address resolution protocol cache table related to the human-machine interaction terminal, and the loss of multicast routes when the reachability of the central electronic module is in a reachable state, so as to perform fault recovery based on the first target fault recovery strategy. The second fault recovery module is used to determine a second target fault recovery strategy based on the abnormal situation of the address resolution protocol cache table related to the central electronic module when the reachability of the central electronic module is unreachable, so as to perform fault recovery based on the second target fault recovery strategy.

Images