Fault processing method and device, electronic equipment and storage medium

Abstract

The application provides a fault processing method and device, electronic equipment and a storage medium, and comprises the following steps: after detecting a fault state, detecting the state of a network; when detecting that the network is continuously in an idle state, closing a controller, starting timing, and the controller being used for connecting the network; when the timing ends, opening the controller, and detecting the state of the network; when detecting that the network is continuously in the idle state, performing data sending, and if one frame of the data is successfully sent, indicating that the network is restored to a working state, the state of other nodes in the network is detected through the state of the network, and after the continuous idle state is monitored, it is judged that the network is in a state before nodes normally send information; at this time, information sending is performed, the possibility of normal operation is improved, and the effectiveness of fault recovery is increased.

Description

Technical Field

[0001] This invention relates to the field of communication technology, and in particular to a fault handling method, apparatus, electronic device, and storage medium. Background Technology

[0002] CAN (Controller Area Network) bus is a serial communication bus widely used in industrial control fields, such as the automotive industry. The CAN bus has a robust error detection and handling mechanism, capable of identifying bit errors, stuffing errors, acknowledgment errors, format errors, and CRC errors. When the controller detects one of these errors, the node sends an error frame, causing the sending node to terminate the currently transmitted valid frame or the receiving node to stop receiving valid frames. After the current error frame is transmitted, the sending node continues to transmit the previous frame, retransmitting the request. When the number of errors accumulates to a specified number, the node will enter a bus-off state.

[0003] After a node enters the bus-off state, it will continuously monitor the bus level until a certain condition is met before it can operate. This can result in a long waiting time, preventing the node from quickly sending emergency messages or receiving messages from the other end and thus hindering its ability to respond promptly, potentially causing accidents during use.

[0004] Therefore, the existing technology involves shutting down the controller for 20ms and then restarting it. The system then checks if the current node has returned to normal operation by retransmitting the data. However, if the transmission fails after restarting, the bus will re-enter the bus-off state, and restarting again will cause the node to repeatedly send and receive error frames. This results in the entire network constantly sending and receiving error frames, impacting the communication efficiency of the entire node network and affecting the real-time performance of other nodes. Summary of the Invention

[0005] This invention provides a fault handling method, apparatus, electronic device, and storage medium to improve the likelihood of normal operation and increase the effectiveness of fault recovery.

[0006] This invention provides a fault handling method, comprising the following steps: after detecting a fault state, detecting the state of the network; when the network is continuously in an idle state, turning off the controller and starting a timer, wherein the controller is used to connect to the network; when the timer ends, turning on the controller and detecting the state of the network; when the network is continuously in an idle state, transmitting data, and if one frame of data is successfully transmitted, it indicates that the system has returned to a working state.

[0007] According to a fault handling method provided by the present invention, the step of detecting the network status after detecting a fault includes: setting the controller to a reset mode after detecting a fault; setting a transmission error counter to a preset value; and detecting the network status, wherein the transmission error counter is used to record the number of errors.

[0008] According to a fault handling method provided by the present invention, the method further includes: if an idle state is detected, decrementing the transmission error counter by a specified value; if a non-idle state is detected, resetting the transmission error counter to the preset value.

[0009] According to a fault handling method provided by the present invention, the method further includes: real-time detection of the value of the transmission error counter; if the value of the transmission error counter is less than a first threshold, then shutting down the controller and starting a timer.

[0010] According to a fault handling method provided by the present invention, the step of activating the controller and detecting the state of the network includes: if an idle state is detected, decrementing the transmission error counter by a specified value; if a non-idle state is detected, resetting the transmission error counter to the preset value; detecting the value of the transmission error counter in real time; if the value of the transmission error counter is less than a second threshold, the network is continuously in an idle state.

[0011] According to a fault handling method provided by the present invention, the method further includes: real-time detection of the value of the transmission error counter; if the value of the transmission error counter is greater than a third threshold, then determining that a fault state has been detected, and increasing the first threshold and the second threshold.

[0012] The present invention also provides a fault handling device, comprising the following modules: a first detection module, used to detect the state of the network after detecting a fault state; a timing module, used to turn off the controller and start timing when the network is continuously idle, the controller being used to connect to the network; a second detection module, used to turn on the controller and detect the state of the network when the timing ends; and a communication module, used to transmit data when the network is continuously idle, and if a frame of data is successfully transmitted, it indicates that the device has returned to a working state.

[0013] The present invention also provides an electronic device, 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 any of the fault handling methods described above.

[0014] The present invention also provides a non-transitory computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the fault handling method as described above.

[0015] The present invention also provides a computer program product, including a computer program that, when executed by a processor, implements any of the fault handling methods described above.

[0016] The fault handling method, apparatus, electronic device, and storage medium provided by this invention detect the working status of other nodes in the network through network status. After detecting a continuous idle state, it is determined that the network is in a state before the node can send information normally. At this time, information is sent, which can improve the possibility of normal operation and increase the effectiveness of fault recovery. Attached Figure Description

[0017] To more clearly illustrate the technical solutions in this invention or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are some embodiments of this invention. For those skilled in the art, other drawings can be obtained from these drawings without creative effort.

[0018] Figure 1 This is a fault state transition diagram provided by the present invention.

[0019] Figure 2 This is one of the flowcharts illustrating the fault handling method provided by the present invention.

[0020] Figure 3 This is the second flowchart of the fault handling method provided by the present invention.

[0021] Figure 4 This is a schematic diagram of the fault handling device provided by the present invention.

[0022] Figure 5 This is a schematic diagram of the structure of the electronic device provided by the present invention. Detailed Implementation

[0023] To make the objectives, technical solutions, and advantages of this invention clearer, the technical solutions of this invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some, not all, of the embodiments of this invention. All other embodiments obtained by those skilled in the art based on the embodiments of this invention without creative effort are within the scope of protection of this invention.

[0024] The CAN bus consists of two signal lines, CANH and CANL. Since it lacks a clock synchronization signal, CAN is an asynchronous communication method. The voltage difference between the two signal lines, CANH-CANL, represents the CAN bus level, corresponding to the transmitted logic signal 1 or 0. The level corresponding to logic 1 is called the recessive level, and the level corresponding to logic 0 is called the dominant level.

[0025] In a CAN bus network, a terminal device on the CAN bus is called a node. There is no distinction between master and slave devices in a CAN network. The hardware of a CAN node generally consists of two parts: a CAN controller and a CAN transceiver. The CAN controller is responsible for the logic control of the CAN bus and implements the CAN transmission protocol; the CAN transceiver is mainly responsible for the conversion between MCU logic levels and CAN bus levels.

[0026] Each node of the CAN controller internally provides a transmit error counter and a receive error counter. Based on these counters, each CAN node can be classified into three fault states: active error state, passive error state, and bus off state. The transition relationship between the three fault states is as follows: Figure 1 As shown.

[0027] like Figure 1 As shown, when both the transmit error counter and the receive error counter are less than 128, the node is in an active error state. In this state, the bus can participate normally in bus activities, transmitting data frames, overload frames, and active error frames. When either the transmit error counter or the receive error counter is greater than or equal to 128 and less than or equal to 255, the node is in a passive error state. In this state, the bus is prone to errors and can transmit data frames, overload frames, and passive error frames. When the transmit error counter is greater than 255, the bus is in a bus-off state, and the node is not allowed to send or receive information.

[0028] In existing technologies, to restore a node from a bus-off state to a working state, the controller is shut down for 20ms and then restarted. The system then checks if the node has returned to normal operation by retransmitting the data. However, if the retransmission fails after restarting, the bus will re-enter a bus-off state, and then restart again. This causes the node to repeatedly send and receive error frames, impacting the communication efficiency of the entire network and affecting the real-time performance of other nodes.

[0029] To address the aforementioned issues, some existing technologies, after entering the busoff state, time the busoff period. When a shutdown threshold is reached, the timer is reset and the CAN controller is shut down. Then, the shutdown duration is timed again, and when the threshold is reached, the node controller is restarted. An attempt is made to send a message; if an error occurs, the counter is incremented, and the process repeats upon entering the busoff state again until successful transmission. While existing technologies use a time-based counting method to shut down and restart the node controller, reducing the average duration of node startup and shutdown, they still exhibit high randomness. This can lead to repeated processes, such as sending frame data, encountering error frames, and then shutting down the bus node, only to repeat the process again.

[0030] In view of this, embodiments of the present invention provide a fault handling method that detects the working status of other nodes in the network by means of network status. After detecting a continuous idle state, it is determined that the network is in a state before the node can send information normally. At this time, information is sent, which can improve the possibility of normal operation and increase the effectiveness of fault recovery.

[0031] The technical solutions of the present invention will now be described with reference to the accompanying drawings in the embodiments of the present invention.

[0032] Figure 2 This is one of the flowcharts illustrating the fault handling method provided by the present invention. The fault handling method can be applied to electronic devices, which can be various types of devices with information processing capabilities during implementation. For example, the electronic device may include a personal computer, laptop computer, PDA, or server; the electronic device may also be a mobile terminal, such as a mobile phone, in-vehicle computer, tablet computer, or projector. Figure 2 As shown, the method may include steps 210 to 250:

[0033] Step 210: After detecting a fault condition, check the network status.

[0034] After a node detects a specified fault condition, it checks the current operating status of the CAN bus.

[0035] For example, the fault state is bus off. After a node enters the bus off state, the CAN controller reports the system busoff status. The CAN controller monitors whether other nodes on the CAN bus are sending messages.

[0036] In one embodiment of this application, detecting the network status after detecting a fault includes: setting the controller to a reset mode after detecting a fault; setting a transmission error counter to a preset value; and detecting the network status, wherein the transmission error counter is used to record the number of errors.

[0037] After reporting the system busoff status, the CAN controller is set to reset mode, the transmit error counter is set to 128, and the receive error counter is set to 0. In this state, the node cannot send or receive information, but this node does not affect the normal communication of other nodes. While in reset mode, the CAN controller can monitor the bus level.

[0038] In one embodiment of this application, the method further includes: if an idle state is detected, decrementing the transmission error counter by a specified value; if a non-idle state is detected, resetting the transmission error counter to the preset value.

[0039] In the CAN bus protocol, the idle state is defined as 11 consecutive invisible levels. During normal operation, the first message must be sent after the bus is detected to be in an idle state.

[0040] The CAN controller listens to the bus level. When it detects 11 consecutive invisible levels, it indicates that an idle state has been detected.

[0041] Each time an idle state is detected, the transmission error counter is decremented by 1. If a non-consecutive 11 recessive bits are detected in the middle, the CAN controller will reset the transmission error counter to 128.

[0042] Step 220: When the network is detected to be continuously idle, the controller is turned off and a timer is started. The controller is used to connect to the network.

[0043] In the CAN bus protocol, an idle state is defined as 11 consecutive invisible voltage levels. The CAN controller determines that an idle state has been detected after detecting 11 consecutive invisible voltage levels.

[0044] In this application, the CAN controller, in addition to detecting the idle state, also determines whether the detected idle states are consecutive, meaning that adjacent idle states cannot contain other states. It should be noted that this application does not impose a limit on the length of the consecutive states; there can be two consecutive idle states or multiple consecutive idle states.

[0045] When the network is detected to be continuously idle, the CAN controller is shut down and a timer is started. Shutting down the CAN controller can temporarily stop a CAN controller experiencing a bus communication failure for a period of time, allowing it to repair its own fault. Alternatively, it can completely remove the faulty CAN controller from the CAN communication line, freeing up CAN communication resources.

[0046] In one embodiment of this application, the method further includes: detecting the value of the transmission error counter in real time; if the value of the transmission error counter is less than a first threshold, then shutting down the controller and starting a timer.

[0047] In the embodiment where the transmission error counter is decremented by 1 for each detected idle state, the transmission error counter is also decremented by N after N consecutive idle state detections. When N reaches the set threshold T, it is determined that the network is continuously in an idle state. The CAN controller is then turned off, and a timer is started.

[0048] Step 230: When the timer ends, turn on the controller and check the status of the network.

[0049] When the timing ends, for example, when the preset threshold T1 is reached, clear the timer. Turn on the CAN controller and then continuously monitor the idle state of the bus.

[0050] In one embodiment of this application, activating the controller and detecting the state of the network includes: if an idle state is detected, decrementing the transmission error counter by a specified value; if a non-idle state is detected, resetting the transmission error counter to the preset value; continuously detecting the value of the transmission error counter; if the value of the transmission error counter is less than a second threshold, the network is continuously in an idle state.

[0051] The CAN controller monitors the bus level. Detecting 11 consecutive recessive bits indicates an idle state. Each time an idle state is detected, the transmit error counter is decremented by 1. If a non-consecutive sequence of 11 recessive bits is detected, the CAN controller resets the transmit error counter to 128.

[0052] When the transmission error counter reaches the preset threshold 128-M, the network is continuously in an idle state. If, after the controller is enabled, a non-idle state occurs during continuous detection of the idle state before reaching the threshold 128-M, the transmission error counter TEC will be set to 128, and the idle state will be detected again.

[0053] Step 240: When the network is detected to be continuously idle, data is transmitted. If a frame of data is successfully transmitted, it indicates that the network has returned to the working state.

[0054] When the transmission error counter reaches the preset threshold of 128-M, the transmission error count is set to 0, the node enters active error state, and exits reset mode.

[0055] The node attempts to send or receive information. Once the first data frame is successfully sent, the node has returned to normal operation. If a node fails to send a frame, its error counter increments according to the error counting rules. If the erroneous frame can be completed normally, the node continues to attempt to send data frames.

[0056] The above-mentioned fault handling method detects the working status of other nodes in the network by monitoring the network status. After detecting a continuous idle state, it is determined that the network is in a state before the node can send information normally. At this time, information is sent, which can increase the possibility of normal operation and increase the effectiveness of fault recovery.

[0057] In one embodiment of this application, the method further includes: real-time detection of the value of the transmission error counter; if the value of the transmission error counter is greater than a third threshold, then determining that a fault state has been detected, and increasing the first threshold and the second threshold.

[0058] The value of the transmission error counter is detected. The error counter includes the transmission error counter and the reception error counter. When the error counter increases to 255 again, the bus enters the Busoff state again. At this time, the values ​​of the adjustment thresholds N and M are doubled, and the above steps 210 to 240 are repeated.

[0059] In the above embodiments, by combining the threshold of the error counter, the value of the error counter is changed, so that the node enters the active error state and sends normal work information, which reduces the waiting time and further improves the node efficiency.

[0060] The following describes an exemplary application of the embodiments of the present invention in a practical application scenario. Figure 3 This is a schematic diagram of the overall process provided in an embodiment of the present invention. Figure 3As shown, after a node enters a bus-off state, the CAN controller reports the system busoff status, sets the controller to reset mode, and the hardware automatically sets the transmit error counter to 128 and the receive error counter to 0. At this time, the bus cannot send or receive information, and this node does not affect the normal communication of other nodes. In reset mode, the controller can monitor the bus level. Each time an idle state is detected (i.e., 11 consecutive invisible levels), the transmit error counter is decremented by 1. After N consecutive idle state checks, the transmit error counter will also decrement by N. When N reaches the set threshold T, the CAN controller is turned off and a timer is started. When the timer reaches the preset threshold T1, the counter value is cleared, the CAN controller is turned on, and then the bus idle state is continuously monitored. When the transmit error counter reaches the preset threshold 128-M, the transmit error counter is set to 0, the node enters an active error state, exits reset mode, and the node attempts to send or receive information. If, after the controller is enabled, a non-idle state occurs during continuous idle state detection before reaching the threshold 128-M, the transmission error counter TEC will be set to 128, and the idle state will be detected again. Once the first data frame is successfully transmitted, it indicates that the node has returned to normal operation. When a node fails to transmit a frame, its transmission error counter will increase according to the error counting rules. If the erroneous frame can be completed normally, the node will continue to attempt to transmit data frames. When the error counter increases to 255 again, the bus enters the Busoff state again. At this time, the values ​​of thresholds N and M will be doubled, and the above operation will be repeated.

[0061] The values ​​of thresholds N and M can be adjusted according to specific circumstances, and T1 is set to 20ms.

[0062] The above method monitors the idle state of the bus to refer to the working state of multiple nodes in the entire system, and compares it with the state before normal information transmission. This makes it more reliable to send information through the restored bus, and further reduces the probability of the bus re-entering Busoff mode due to the above method being used to restore the bus.

[0063] The above method configures the transmission error count through thresholds N and M, allowing the bus to enter the active error state more quickly and enter the working state with less waiting time.

[0064] Based on the foregoing embodiments, this invention provides an apparatus in which each module and each unit included in the module can be implemented by a processor; of course, it can also be implemented by specific logic circuits; in the implementation process, the processor can be a central processing unit (CPU), a microprocessor (MPU), a digital signal processor (DSP), or a field programmable gate array (FPGA), etc.

[0065] The fault handling device provided by the present invention is described below. The fault handling device described below can be referred to in correspondence with the fault handling method described above.

[0066] Figure 4 This is a schematic diagram of the fault handling device provided in an embodiment of the present invention. Figure 4 As shown, the device 400 includes a first detection module 410, a timing module 420, a second detection module 430, and a communication module 440, wherein:

[0067] The first detection module 410 is used to detect the status of the network after a fault condition is detected;

[0068] The timing module 420 is used to turn off the controller and start timing when the network is detected to be continuously idle. The controller is used to connect to the network.

[0069] The second detection module 430 is used to activate the controller and detect the status of the network when the timing ends;

[0070] The communication module 440 is used to send data when the network is detected to be continuously idle. If a frame of data is successfully sent, it indicates that the network has returned to the working state.

[0071] In some embodiments, the first detection module 410 is specifically used to set the controller to a reset mode after a fault is detected; set the transmission error counter to a preset value; and detect the status of the network, wherein the transmission error counter is used to record the number of errors.

[0072] In some embodiments, the first detection module 410 is further configured to decrement the transmission error counter by a specified value if an idle state is detected, and to reset the transmission error counter to the preset value if a non-idle state is detected.

[0073] In some embodiments, the first detection module 410 is further configured to detect the value of the transmission error counter in real time; if the value of the transmission error counter is less than a first threshold, the controller is turned off and timing begins.

[0074] In some embodiments, the second detection module 430 is further configured to: if an idle state is detected, decrement the transmission error counter by the specified value; if a non-idle state is detected, reset the transmission error counter to the preset value; detect the value of the transmission error counter in real time; if the value of the transmission error counter is less than a second threshold, the network is continuously in an idle state.

[0075] The above-mentioned device further includes: a third detection module, which is used to detect the value of the transmission error counter in real time; if the value of the transmission error counter is greater than a third threshold, it is determined that a fault state has been detected, and the first threshold and the second threshold are increased.

[0076] Figure 5 This is a schematic diagram of the physical structure of the electronic device provided by the present invention, such as... Figure 5 As shown, the electronic device may include a processor 510, a communications interface 520, a memory 530, and a communication bus 540, wherein the processor 510, communications interface 520, and memory 530 communicate with each other via the communication bus 540. The processor 510 can call logical instructions in the memory 530 to execute a fault handling method, which includes: detecting the network status after detecting a fault state; when the network is continuously idle, turning off the controller and starting a timer (the controller is used to connect to the network); when the timer ends, turning on the controller and detecting the network status; and when the network is continuously idle, transmitting data, and if one frame of data is successfully transmitted, it indicates a return to the working state.

[0077] Furthermore, the logical instructions in the aforementioned memory 530 can be implemented as software functional units and, when sold or used as independent products, can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the present invention, or the part that contributes to the prior art, or a part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of the present invention. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0078] On the other hand, the present invention also provides a computer program product, which includes a computer program that can be stored on a non-transitory computer-readable storage medium. When the computer program is executed by a processor, the computer can perform the fault handling methods provided by the above methods. The method includes: detecting the network status after detecting a fault state; turning off the controller and starting a timer when the network is continuously in an idle state, the controller being used to connect to the network; turning on the controller and detecting the network status when the timer ends; and transmitting data when the network is continuously in an idle state, and if one frame of data is successfully transmitted, it indicates that the system has returned to a working state.

[0079] The computer program product includes one or more computer instructions. When the computer program instructions are loaded and executed on a computer, all or part of the processes or functions described in the embodiments of the present invention are generated. The computer may be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions may be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another. For example, the computer instructions may be transmitted from one website, computer, server, or data center to another website, computer, server, or data center via wired (e.g., coaxial cable, fiber optic, digital subscriber line (DSL)) or wireless (e.g., infrared, wireless, microwave, etc.) means. The computer-readable storage medium may be any available medium that a computer can store or a data storage device such as a server or data center that integrates one or more available media. The available medium may be a magnetic medium (e.g., floppy disk, hard disk, magnetic tape), an optical medium (e.g., DVD), or a semiconductor medium (e.g., a solid-state disk (SSD)).

[0080] In another aspect, the present invention also provides a non-transitory computer-readable storage medium having a computer program stored thereon. When executed by a processor, the computer program is implemented to perform the fault handling methods provided by the above methods. The method includes: detecting the state of the network after detecting a fault state; turning off the controller and starting a timer when the network is continuously in an idle state, the controller being used to connect to the network; turning on the controller and detecting the state of the network when the timer ends; and transmitting data when the network is continuously in an idle state, wherein if a frame of data is successfully transmitted, it indicates that the system has returned to a working state.

[0081] The aforementioned computer-readable storage medium may be any combination of one or more computer-readable media. A computer-readable medium may be a computer-readable signal medium or a computer-readable storage medium. A computer-readable storage medium may be, for example,—but not limited to—an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination thereof. More specific examples of computer-readable storage media (a non-exhaustive list) include: an electrical connection having one or more wires, a portable computer disk, a hard disk, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM) or flash memory, optical fiber, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination thereof. In this document, a computer-readable storage medium may be any tangible medium that contains or stores a program that can be used by or in connection with an instruction execution system, apparatus, or device.

[0082] Computer-readable signal media may include data signals propagated in baseband or as part of a carrier wave, carrying computer-readable program code. Such propagated data signals may take various forms, including—but not limited to—electromagnetic signals, optical signals, or any suitable combination thereof. Computer-readable signal media may also be any computer-readable medium other than computer-readable storage media, capable of transmitting, propagating, or transmitting programs for use by or in connection with an instruction execution system, apparatus, or device.

[0083] Program code contained on a computer-readable medium may be transmitted using any suitable medium, including—but not limited to—wireless, wire, optical fiber, radio frequency (RF), etc., or any suitable combination thereof.

[0084] Computer program code for performing the operations described herein can be written in one or more programming languages ​​or a combination thereof, including object-oriented programming languages ​​such as Java, Smalltalk, and C++, and conventional procedural programming languages ​​such as "C" or similar languages. The program code can be executed entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In cases involving remote computers, the remote computer can be connected to the user's computer via any type of network—including a local area network (LAN) or a wide area network (WAN), or it can be connected to an external computer (e.g., via the Internet using an Internet service provider).

[0085] The device embodiments described above are merely illustrative. The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the modules can be selected to achieve the purpose of this embodiment according to actual needs. Those skilled in the art can understand and implement this without any creative effort.

[0086] Through the above description of the embodiments, those skilled in the art can clearly understand that each embodiment can be implemented by means of software plus necessary general-purpose hardware platforms, and of course, it can also be implemented by hardware. Based on this understanding, the above technical solutions, in essence or the part that contributes to the prior art, can be embodied in the form of a software product. This computer software product can be stored in a computer-readable storage medium, such as ROM / RAM, magnetic disk, optical disk, etc., and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute the methods described in the various embodiments or some parts of the embodiments.

[0087] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention, and not to limit them; although the present invention 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; and these 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 the present invention.

Claims

1. A failure handling method characterized by, The method comprises: detecting the state of the network after detecting a fault state; turning off a controller for connecting the network when detecting that the network is continuously in an idle state, and starting timing; turning on the controller and detecting the state of the network when the timing ends; sending data when detecting that the network is continuously in the idle state, and representing a recovery to a working state if one frame of the data is successfully sent. The detecting the state of the network after detecting a fault state comprises: setting the controller to a reset mode after detecting a fault state; setting a sending error counter to a preset value, and detecting the state of the network, wherein the sending error counter is used to record the number of errors. The turning on the controller and detecting the state of the network comprises: decreasing the sending error counter by a specified value if one idle state is detected; resetting the sending error counter to the preset value if one non-idle state is detected; real-time detecting the value of the sending error counter; detecting that the network is continuously in the idle state if the value of the sending error counter is less than a second threshold value.

2. The method of claim 1, wherein, The method further comprises: decreasing the sending error counter by the specified value if one idle state is detected; resetting the sending error counter to the preset value if one non-idle state is detected.

3. The method of claim 2, wherein, The method further comprises: real-time detecting the value of the sending error counter; turning off the controller and starting timing if the value of the sending error counter is less than a first threshold value.

4. The method of claim 1, wherein, The method further comprises: real-time detecting the value of the sending error counter; detecting a fault state and increasing the first threshold value and the second threshold value if the value of the sending error counter is greater than a third threshold value.

5. A failure handling apparatus characterized by comprising: The method comprises: a first detecting module, configured to detect the state of the network after detecting a fault state; a timing module, configured to turn off a controller for connecting the network when detecting that the network is continuously in an idle state, and start timing; a second detecting module, configured to turn on the controller and detect the state of the network when the timing ends; a communication module, configured to send data when detecting that the network is continuously in the idle state, and represent a recovery to a working state if one frame of the data is successfully sent. The first detecting module is further configured to set the controller to a reset mode after detecting a fault state, and set a sending error counter to a preset value and detect the state of the network, wherein the sending error counter is used to record the number of errors. The second detecting module is further configured to decrease the sending error counter by a specified value if one idle state is detected, reset the sending error counter to the preset value if one non-idle state is detected, real-time detect the value of the sending error counter, and detect that the network is continuously in the idle state if the value of the sending error counter is less than a second threshold value.

6. An electronic device comprising a memory, a processor, and a computer program stored on the memory and executable on the processor, characterized in that, The processor implements the fault processing method according to any one of claims 1 to 4 when executing the computer program.

7. A non-transitory computer-readable storage medium having stored thereon a computer program, characterized in that, The computer program is executed by the processor to implement the fault processing method according to any one of claims 1 to 4.

8. A computer program product comprising a computer program, characterized in that, The computer program, when executed by a processor, implements the fault handling method according to any one of claims 1 to 4.

Images