New approach for controller area network bus off handling

BACKGROUND OF THE INVENTION

00011. Field of the Invention

0002This invention relates generally to a system and method for resetting a controller in response to a controller area network (CAN) bus off state and, more particularly, to a system and method for resetting an electronic control unit (ECU) on a vehicle in response to a CAN controller bus off state that includes differentiating between internal ECU faults and random external disturbances.

00032. Discussion of the Related Art

0004Most modern vehicles include many electronic control units (ECUs) or controllers that control the operation of various vehicle systems, such as power train, climate control system, infotainment system, body systems, chassis systems, etc. Such controllers and ECUs require special purpose and designed software that allow them to perform their control functions. Many or all of the ECUs associated with a particular vehicle system are typically part of a distributed controller area (CAN) network that employs a CAN bus in electrical communication with the several ECUs that allows for the transmission of messages between the ECUs. Each ECU includes a hardware circuit known as a CAN controller that controls the transmission of messages onto the CAN bus and the receipt of messages from the CAN bus. The CAN controller provides signals to a host application layer on the ECU that includes the software that operates the ECU for the particular purpose.

0005Message errors occur when the CAN controller determines that a message has an improper header format or other improper configuration. Errors can occur as a result of random external disturbances, such as EMI pulses, or internal controller faults. If the CAN controller in an ECU receives a message from the CAN bus and determines that the message has an error, that CAN controller can corrupt the message so that it is not usable by other ECUs coupled to the bus. If a faulty CAN controller improperly corrupts a message because it thinks it has an error when it does not, then the other ECUs in the CAN network cannot use the message when they should be able to.

0006Each CAN controller in a CAN network typically operates in one of three states, namely, an error active state, an error passive state and a bus off state. When a CAN controller is in its active mode or error active state and providing messages to and receiving messages from the CAN bus, errors of the type as discussed above may occur where the transmission of data to or the reception of data from the bus has failed. The CAN controller may send active error flags onto the bus to corrupt messages on the bus as mentioned above. The CAN controller accumulates the errors over time and when the number of errors for the reception of messages, as accumulated by a receive error counter (REC) in the CAN controller, or when the number of errors for the transmission of messages, as accumulated by a transmission error counter (TEC) in the CAN controller, reaches a predetermined value, such as 127, the CAN controller enters the error passive state, where it cannot corrupt messages on the bus. During the error passive state, the TEC will continue to accumulate transmission errors and once a second count value has been reached, such as 255, the CAN controller enters a bus off state and is disconnected from the CAN bus. Thus, by putting the CAN controller in the error passive state once is has accumulated a predetermined number of errors, the CAN controller is prevented from corrupting messages that would otherwise be valid for the other ECUs in the network, and then when the transmission of errors reaches another predetermined value, the CAN controller is prevented from transmitting error messages onto the bus that would otherwise be acted on by other ECUs in the network.

0007The CAN controller notifies the application layer when the bus off state occurs. The application layer is programmed with a certain protocol that allows it to reset the CAN controller after a bus off state occurs so that the CAN controller can again become active to send and transmit messages on the CAN bus. Thus, the CAN controller remains in the bus off state until the application layer initiates the reset of the CAN controller to the error active state. Different CAN networks employ different types of bus off reset policies to determine how and when the application layer resets the CAN controller.

0008In one known bus off reset policy, referred to as an auto-reset policy, the application layer initiates the reset of the CAN controller immediately after the CAN controller enters the bus off state and the CAN controller returns to the error active state after it receives a predetermined number of recessive bits a predetermined number of times, such as 128 recessive bits 11 times. However, if the CAN controller itself is faulty and the application layer immediately resets the CAN controller, the CAN controller would repeatedly interrupt the normal vehicle control.

0009In another known bus off reset policy, referred to as a wait-then-reset policy, the application layer will wait some predetermined period of time after the bus off state occurs to give the CAN controller time to recover from the fault condition. However, as mentioned, there are certain CAN controller error conditions caused by external interferences, such as electromagnetic radiation, that are random and periodic and do not last for very long. If the bus off reset policy is to wait and then reset the CAN controller to the error active state, and the result of the error is an external disturbance, then the CAN controller will be offline for some period of time where the interference probably is still not causing problems. During this time, the particular CAN controller will not be able to put messages onto the bus, possibly effecting vehicle operation and performance. Therefore, a CAN controller that is waiting for a message from another CAN controller that is in the wait period for the bus off reset policy may set a diagnostic trouble code (DTC) that indicates that the CAN controller is not available to send messages.

0010In another known bus off reset policy, referred to as a frequency-limited-reset policy, it is required that the time between any two subsequent resets must be larger than a predetermined time interval. For this case, if a second bus off state occurs after the predetermined time interval from the reset of the first bus off state then the application layer immediately resets the CAN controller. However, for a faulty controller, too small of a time interval between the resets would result in the immediate reset of the CAN controller for a bus off state and the CAN controller would have no time to recover from the fault resulting in continuous interference of the normal communications on the bus, and too long of a time interval would result in unnecessary interruption of the CAN controller when not being connected to the bus. Analysis has shown that no appropriate time interval between bus off state and reset can satisfactorily address the above situations.

SUMMARY OF THE INVENTION

0011In accordance with the teachings of the present invention, a system and method are disclosed for determining when to reset a controller in response to a bus off state that occurs as a result of errors identified in messages transmitted on or received from a controller area network (CAN) bus, where the bus off state causes the controller to be disconnected from CAN bus. The method includes determining that the controller has entered a first bus off state and immediately resetting the controller in response to determining that the controller has entered the first bus off state. The method further includes setting a reset timer in response to the controller being reset, determining whether the controller has entered a subsequent bus off state after the controller has been reset, and determining whether a reset time from when the controller is reset until the subsequent bus off state is greater than a first predetermined time interval. The method immediately resets the controller in response to the subsequent bus off state if the reset time is greater than the first predetermined time interval, and resets the controller in response to the subsequent bus off state after a second predetermined time interval has elapsed if the reset time is less than the first predetermined time interval.

0012Additional features of the present invention will become apparent from the following description and appended claims, taken in conjunction with the accompanying drawings.

BRIEF DESCRIPTION OF THE DRAWINGS

0013<figref idref="DRAWINGS">FIG. 1</figref> is an illustration of a plurality of ECUs coupled to a CAN bus;

0014<figref idref="DRAWINGS">FIG. 2</figref> is a state diagram showing the states of a CAN controller in the ECUs shown in <figref idref="DRAWINGS">FIG. 1</figref>;

0015<figref idref="DRAWINGS">FIG. 3</figref> is a time line showing a first solution for a bus off reset policy;

0016<figref idref="DRAWINGS">FIG. 4</figref> is a time line showing a second solution for a bus off reset policy;

0017<figref idref="DRAWINGS">FIG. 5</figref> is a flow chart diagram showing a process for implementing the bus off reset policy illustrated in <figref idref="DRAWINGS">FIG. 3</figref>; and

0018<figref idref="DRAWINGS">FIG. 6</figref> is a flow chart diagram showing a process for implementing the bus off reset policy illustrated in <figref idref="DRAWINGS">FIG. 4</figref>.

DETAILED DESCRIPTION OF THE EMBODIMENTS

0019The following discussion of the embodiments of the invention directed to a system and method for providing a CAN controller bus off reset policy is merely exemplary in nature, and is in no way intended to limit the invention or its applications or uses. For example, the present invention has application for resetting CAN controllers in ECUs associated with a vehicle. However, as will be appreciated by those skilled in the art, the present invention will have application for other controllers.

0020<figref idref="DRAWINGS">FIG. 1</figref> is an illustration of a CAN network <b>10</b> including a plurality of ECUs <b>12</b> coupled to a CAN bus <b>14</b>. The CAN network <b>10</b> is intended to be a general representation of any CAN network on a vehicle that includes any number of ECUs for any applicable vehicle system. Messages transmitted by and received from a particular ECU <b>12</b> are provided on the bus <b>14</b> to be received by and acted on by other of the ECUs <b>12</b> in the network <b>10</b> in a manner that is well understood by those skilled in the art. As discussed above, each ECU <b>12</b> includes a hardware chip referred to as a CAN controller <b>16</b> that controls the transmission of messages onto the CAN bus <b>14</b> and the receipt of messages from the CAN bus <b>14</b>. The CAN controller <b>16</b> provides signals to a host application layer <b>18</b> on the ECU <b>12</b> that includes the software that operates the ECU <b>12</b> for the particular purpose. When the CAN controller <b>16</b> enters a bus off state, it notifies the host application layer <b>18</b> of that condition.

0021<figref idref="DRAWINGS">FIG. 2</figref> is a representation of a CAN controller state diagram <b>20</b> showing the CAN controller states referred to above. Particularly, the state diagram <b>20</b> shows an active error state <b>22</b>, an error passive state <b>24</b> and a bus off state <b>26</b>.

0022The present invention proposes a bus off reset policy that effectively differentiates between errors caused by external random disturbances and errors cause by internal controller faults. Analysis has shown that a bus off state caused by an internal controller fault is reached quickly, for example, less than 1 second, i.e., the TEC reaches the predetermined error count from TEC=0 after a reset to the error active state <b>22</b>, and a bus off state caused by an external random disturbance is reached more slowly, for example, more than 100 seconds. To provide this differentiation, the present invention looks at the time from a first bus off state to a next bus off state, and if that time is greater than a predetermine calibratable time interval, the CAN controller determines that the errors are caused by an external disturbance, and if that time is less than or equal to the time interval, the CAN controller determines that the errors are caused by an internal controller fault. As discussed herein, if the bus off state is caused by an internal controller fault, then some reset time is desired to give the CAN controller <b>16</b> an opportunity to recover from the fault. However, if the bus off state is caused by an external disturbance, then the disturbance is typically very quick and the CAN controller <b>16</b> can be reset immediately.

0023For bus off states caused by an internal controller fault, it has been shown that the time from one bus off state reset, TEC=0, to the next bus off state <b>26</b> for a high speed CAN controller, for example, 500 Kb/s, is less than 10 seconds when the frame error rate is greater than 0.12 and less than 1 second when the frame error rate is greater than 0.21. It has also been shown that the time from one bus off state reset, TEC=0, to the next bus off state <b>26</b> for a low speed CAN controller, for example, 33.3 Kb/s, is less than 10 seconds when the frame error rate is greater than 0.25 and less than 1 second when the frame error rate is 0.7.

0024For bus off states caused by external disturbances in a high speed CAN controller, it has been shown that the time from one bus off state reset to the next bus off state <b>26</b> is more than 1300 seconds in a harsh EMI environment, including a bit error rate 10³. For a low speed CAN controller, the time from one bus off state reset to the next bus off state <b>26</b> is more than 19000 seconds in a harsh EMI environment.

0025The values given above are for the time from when the CAN controller <b>16</b> enters the active error state <b>22</b> to when it enters the bus off state <b>26</b>. For those CAN controllers that also employ the error passive state <b>24</b>, the same values can be calculated from the time between when the CAN controller <b>16</b> enters the error passive state <b>22</b> to when it enters the bus off state <b>26</b>. Particularly, for bus off states caused by an internal controller fault, it has been shown that for a high speed CAN controller, the time between when the controller <b>16</b> enters the error passive state to when it enters the bus off state is typically less than 10 seconds when the frame error rate is greater than 0.11 and less than 1 second when the frame error rate is greater than 0.16. For low speed CAN controllers, it has been shown that the time between when the controller <b>16</b> enters the error passive state <b>24</b> to when it enters the bus off state <b>26</b> is less than 10 seconds when the frame error rate is greater than 0.18 and less than 1 second when the frame error rate is greater than 0.55.

0026For bus off states caused by external disturbances, it has been shown that for a high speed CAN controller, the time between when the controller <b>16</b> enters the error passive state <b>24</b> to when it enters the bus off state <b>26</b> is typically greater than 35 seconds in a harsh EMI environment and for a low speed CAN controller is typically greater than 510 seconds in a harsh EMI environment.

0027Based on the foregoing, when the bus off state <b>26</b> occurs in the CAN controller <b>16</b> as a result of the accumulation of errors as described, the CAN controller <b>16</b> reports the bus off state <b>26</b> to the application layer <b>18</b>, which enters an interrupt routine that includes starting a timer to determine when the next bus off state occurs, and if that time is less than or equal to a calibratable time interval X, then the bus off state <b>26</b> can be assumed to be a result of errors caused by a faulty controller, and if that time is greater than the time interval X, then the bus off state <b>26</b> can be assumed to be a result of errors caused by external disturbances. If the time is less than the time interval X, then the application layer <b>18</b> can set a calibratable reset wait time interval Y before resetting the CAN controller <b>16</b> to allow the CAN controller <b>16</b> to recover from the fault. If the time is greater than the time interval X, then the application layer <b>18</b> can immediately reset the CAN controller <b>16</b>. Both the time intervals X and Y are calibratable for low speed and high speed CAN controllers, for example, the time interval X can be 1 second for a high speed CAN controller and 10 seconds for a low speed CAN controller, and the time interval Y can be 100 ms for a high speed CAN controller and 1 second for a low speed CAN controller.

0028<figref idref="DRAWINGS">FIG. 3</figref> is a timing diagram <b>30</b> illustrating a first solution bus off reset policy for a CAN controller that does not report an error passive state to the application layer <b>18</b>. If the first bus off state <b>26</b> occurs at time <b>32</b>, the CAN controller <b>16</b> is immediately reset and a timer is started. If the timer provides a time T₁at time <b>34</b> when the next bus off state <b>26</b> occurs, the application layer <b>18</b> determines whether the time T₁is greater than or less than the time interval X. If the time T₁is greater than the time interval X, meaning the bus off state <b>26</b> occurred because of random disturbance, then the application layer <b>18</b> immediately resets the CAN controller <b>16</b>, and if the time T₁is less than or equal to the time interval X, meaning the bus off state <b>26</b> occurred because of a faulty controller, then the application layer <b>18</b> waits the time interval Y before it resets the CAN controller <b>16</b> to give the controller <b>16</b> time to recover from the fault. The same process is performed for times T₂and T₃associated with bus off reset time <b>36</b> and the next bus off state time <b>38</b> and the bus off reset time <b>40</b> and the next bus off state time <b>42</b>, respectively.

0029The above described bus off reset policy has the disadvantage that since the first bus off state at time <b>32</b> is always treated as a an immediate reset even if it is a faulty controller, the faulty controller could be still be operating for the time T₁, for example, 1 second, before the next bus off state occurs when the time T₁can be used to determine if the bus off state <b>26</b> was caused by a faulty controller or an external disturbance based on the time interval X, in which case time T₁would be less than or equal to the time interval X since the bus off is caused by the faulty controller, and only after the second bus off at time <b>34</b> a wait-time is provided at its reset. As a result, the bus interference from the faulty ECU will continue for the time T₁until the next bus off state <b>26</b> at the time <b>34</b>. Thus, the bus interruption occurs for an additional 1 second beyond what would be desirable.

0030This disadvantage can be addressed by counting the time between when the error passive state <b>24</b> is reached and the bus off state <b>26</b> is reached, which is typically very quickly. This second solution bus off reset policy is illustrated by timing diagram <b>50</b> in <figref idref="DRAWINGS">FIG. 4</figref> where a timer is started when the CAN controller <b>16</b> enters the first error passive state <b>24</b> before the first bus off state <b>26</b> occurs. The time T₀from when the first error passive state <b>24</b> is entered at time <b>52</b> and the first bus off state <b>26</b> occurs at time <b>54</b> is compared to the time interval X to determine if the bus off state <b>26</b> is caused by a faulty controller or an external disturbance. If the bus off state <b>26</b> is caused by a faulty controller, then the time T₀will be less than or equal to the time interval X, and the application layer <b>18</b> treats the bus off state <b>26</b> as an internal fault and resets the CAN controller <b>16</b> after the delay of the time interval Y. If the bus off state <b>26</b> was caused by an external disturbance, the time T₀will be greater than the time interval X and the application layer <b>18</b> will immediately reset the CAN controller <b>16</b>. The same process is performed for times T₁, T₂and T₃for error passive state time <b>56</b> and bus off state time <b>58</b>, error passive state time <b>60</b> and bus off state time <b>62</b>, and error passive state time <b>64</b> and bus off state time <b>66</b>, respectively.

0031Thus, if the CAN controller <b>16</b> does report the error passive state <b>24</b> to the application layer <b>18</b>, then the ECU <b>12</b> can use the second solution for its bus off reset policy, and if the CAN controller <b>16</b> does not report the error passive state <b>24</b> to the application layer <b>18</b>, then the ECU <b>12</b> can use the first solution for its bus off reset policy.

0032For the first solution where the bus off state determination is based on the time from the last bus off reset, the performance is slightly reduced because the application layer <b>18</b> is unable to identify the first bus off state for a faulty ECU. However, there is no additional cost to the CAN controller <b>16</b> to report the error passive state <b>24</b>. For the second solution, for the bus off state differentiation based on the time from the error passive state <b>24</b>, the performance of the bus off reset policy is increased because of the correct identification of the first bus off for a faulty ECU, however, there is additional cost for the CAN controller <b>16</b> to report the error passive state <b>24</b>.

0033<figref idref="DRAWINGS">FIG. 5</figref> is a flow chart diagram <b>80</b> showing a process for providing the bus off reset policy set forth for the first solution discussed above as illustrated in <figref idref="DRAWINGS">FIG. 3</figref>. When the CAN controller <b>16</b> enters the bus off state it notifies the application layer <b>18</b> by a CAN interrupt routine that includes setting a bus off state flag indicating the bus off state <b>26</b>. The algorithm in the application layer <b>18</b> running the CAN bus off handling algorithm periodically at a time period T_a, such as 10-20 milliseconds, which is less than the time intervals X and Y, to monitor the bus off state flag and perform the bus off reset policy for resetting the CAN controller <b>16</b> to the active error state <b>22</b>. In this embodiment, the timers for the time intervals X and Y count down from their value to zero when they are started when the bus off state <b>26</b> is entered. Initially, both the timers for the time intervals X and Y are set to zero. When the algorithm enters the process when the time period T_ahas elapsed, the algorithm determines whether the timer for the time interval X is set to zero, and if not, decreases the timer for the time interval X by the time period T_aat box <b>82</b>, and determines whether the timer for the time interval Y is set to zero, and if not, decreases the timer for the time interval Y by the time period T_aat box <b>84</b>. Thus, if either or both of the timers for the time intervals X and Y are running when the process is initiated, they are decreased by the time period T_aon their way to zero.

0034At decision diamond <b>86</b>, the algorithm determines whether the bus off flag has been set to 1 meaning that a bus off state has occurred, and if not, the algorithm ends at box <b>88</b> to wait for the next time period T_a. If the bus off flag has been set to 1 at the decision diamond <b>86</b>, then the algorithm determines whether the timer for the time interval X is equal to zero at decision diamond <b>90</b>. When the reset of a bus off state <b>26</b> occurs, the timer for the time interval X is set and begins to count down in increments of T_afrom the time value X to zero to determine if the next bus off state <b>26</b> has occurred relative to the time. If the timer for the time interval X is not equal to zero, then the bus-off state <b>26</b> occurred before the end of the time interval X, here 1 second, meaning that the bus-off state <b>26</b> occurred because of a faulty ECU. In this situation, the timer for the time interval X is set to zero and the timer for the time interval Y is set to the time interval Y at box <b>92</b> to cause the controller <b>16</b> to be reset after the time interval Y expires, and the algorithm ends at the box <b>88</b>.

0035If the timer for the time interval X is equal to zero at the decision diamond <b>90</b>, meaning that the bus off state <b>26</b> occurred after the timer for the time interval X elapsed and the bus off state <b>26</b> is the result of random disturbances and the timer for the time interval Y for the wait-time of the reset is proceeding, the algorithm then determines whether the timer for the time interval Y is zero at decision diamond <b>94</b>. If the timer for the time interval Y is not zero at the decision diamond <b>90</b>, then the algorithm is still waiting for the wait-time to elapse for when it can be reset and the algorithm ends at the box <b>88</b>. If the timer for the time interval Y is equal to zero at the decision diamond <b>94</b>, meaning that the ECU <b>12</b> has been in the bus off state for the desired period of time to recover from the fault, the algorithm proceeds to box <b>96</b> to initiate the reset of the CAN controller <b>16</b> to the error active state <b>22</b>, set the bus-off flag to zero and reset the timer for the time interval X to its time value, and the algorithm ends at the box <b>88</b>.

0036<figref idref="DRAWINGS">FIG. 6</figref> is a flow chart diagram <b>100</b> showing the operation for the bus off reset policy for the second solution discussed above with reference to <figref idref="DRAWINGS">FIG. 4</figref>, where like boxes to the flow chart diagram <b>80</b> have the same reference number. For this bus off reset policy, the interrupt routine sets both the bus off flag when the ECU <b>12</b> is in the bus off state <b>26</b> and an error passive state flag when the CAN controller <b>16</b> is in the error passive state <b>24</b>. In this process, after the timers for the time intervals X and Y have been decreased by the period T_a, the algorithm determines whether the CAN controller <b>16</b> is in the error passive state <b>24</b> by determining if the error passive state flag has been set at decision diamond <b>102</b> before it determines whether the bus-off flag has been set to 1. If the error passive state <b>24</b> has not been entered at the decision diamond <b>102</b>, then the algorithm proceeds directly to the decision diamond <b>86</b> to determine if the bus off state flag is set. However, if the error passive state <b>24</b> has been entered at the decision diamond <b>102</b>, then the algorithm sets the timer for the time interval X to its value, here 1 second, at box <b>104</b> because the reset is based on the time from when the CAN controller <b>16</b> enters the error passive state <b>24</b>. The algorithm also sets the error passive flag to zero at the box <b>104</b> before it proceeds to determining whether the bus-off flag has been set at the decision diamond <b>86</b>. The CAN controller is reset and the bus off flag is set to zero at box <b>106</b>, where the time interval X is not set at the box <b>106</b> when the CAN controller <b>16</b> is reset because it was reset at the box <b>104</b>.

0037As will be well understood by those skilled in the art, the several and various steps and processes discussed herein to describe the invention may be referring to operations performed by a computer, a processor or other electronic calculating device that manipulate and/or transform data using electrical phenomenon. Those computers and electronic devices may employ various volatile and/or non-volatile memories including non-transitory computer-readable medium with an executable program stored thereon including various code or executable instructions able to be performed by the computer or processor, where the memory and/or computer-readable medium may include all forms and types of memory and other computer-readable media.

0038The foregoing discussion discloses and describes merely exemplary embodiments of the present invention. One skilled in the art will readily recognize from such discussion and from the accompanying drawings and claims that various changes, modifications and variations can be made therein without departing from the spirit and scope of the invention as defined in the following claims.