FORM 2
THE PATENTS ACT 1970 [39 OF 1970]
&
THE PATENTS RULES, 2003
COMPLETE SPECIFICATION
[See section 10 and rule 13]
Title: “A METHOD OF DETECTING OPEN CIRCUIT FAILURE IN CONTROLLER AREA NETWORK (CAN)”
Name and address of the Applicant:
TATA MOTORS LIMITED, Pimpri, Pune 411 018, Maharashtra, India
Nationality: India
The following specification particularly describes the invention and the manner in which it is to be performed.

TECHNICAL FIELD
The present disclosure relates to communication networks where different electronic control units (ECU) communicate with each other over controller area network (CAN) protocol. More specifically, it is related to a method and device for detecting open circuit failure by pin pointing location of the failure in CAN network cable of any electronic control unit.
BACKGROUND AND PRIOR ART
With the advent of distributed control functionalities the need has arisen for reliable communication network systems where different electronic control units (ECUs) are connected with each other through controller area network (CAN network) buses for sharing hundreds of critical signals. Typical applications of such network systems are widely seen in automotive domain, where in-vehicle networks are used as the backbone of all distributed control functions. So, improving reliability and diagnosability of such networks is of utmost importance for vehicle manufacturers to detect field failures faster in vehicle service stations and to minimize vehicle down time.
Existing methodologies for network diagnostics for CAN networks mainly deals with detecting different network physical open circuit and short circuit conditions by applying node monitoring mechanisms like receive-message time-out concept at network management layer. If there is any open circuit in the network then depending on the location of the open circuit few ECUs will fail to receive CAN messages from the transmitter ECU and thereby triggering node monitoring detection mechanisms to log receive-message time-out failures. So, maturation of these receive-message time-out failures is mapped to the open circuit failure as one of the causes of failures. Detection of receive message time-out is one of the typical detection mechanisms for detection of network management failures. Existing practice tries to map network management related failure detection mechanism to detect physical failure of networks.
For example, US patent Application Publication No. 20080186870 filed on January 29, 2008 talks about a method and system for monitoring a communications network, e.g.,

a controller area network (CAN), and more specifically, an in-vehicle communications network, by maintaining a count of each type of error code and a histogram of all network messages seen by each of the controller during a measurement period; and by determining a bus health index of the communication us based upon a percentage of a given type of error to the count of all errors during measurement period. The Application 20080186870 only captures how different failures can be observed in CAN network to compute the bus health index which is determined by computing a percentage of a given error count with respect to the total error count. Therefore, the Application 20080186870 lacks in identifying actual cause of the failure and location of the failure.
The problem associated with existing practice is that there could be many reasons for receive-message time-out failures apart from physical network open circuit conditions. For example, any sudden failure in operating tasks inside ECU may result in interruption in transmission of CAN messages. Node monitoring using only receive-message time-out concept will classify such type of ECU’s internal failure also as physical open circuit failure. Existing methods fail to distinguish between physical open circuit failure of the network and internal failure of ECU operations.
Existing method also can not detect the location of the open circuit failure; whether the open circuit has occurred in the main bus or in any branch of the main bus. Hence, the existing detection methods fail to pin point the physical open circuit failures of the network resulting in longer time for failure detection for networks in the field.
SUMMARY
The shortcomings of the prior art are overcome and additional advantages are provided through the provision of a method as claimed in claim 1, and corresponding system.
Additional features and advantages are realized through the techniques of the present disclosure. Other embodiments and aspects of the disclosure are described in detail herein and are considered a part of the claimed disclosure.

An exemplary embodiment provides a method of detecting open circuit failure by pin pointing the location of the failure which includes monitoring (a) CAN Error-Passive failure, (b) CAN receive-message Time-out failure, and (c) CAN transmit-message Time-out failure, in any combination, in transmitting and receiving Electronic Control Units (ECUs), and recording corresponding Diagnostic Trouble Code (DTC) in the ECU to detect the open circuit failure.
In an exemplary embodiment, the method proposes detection and classification of local open circuit failure in network, global open circuit failure in network and ECU internal failure includes deploying CAN Error-Passive monitoring to detect local open circuit failure in network, deploying CAN receive-message time-out monitoring to detect global open circuit failure in network and deploying CAN transmit-message timeout monitoring to detect internal failure in operating tasks within ECU. Deployment of all three detection methods helps in distinguishing the actual root cause of the failure and thus improves network diagnostic. It also proposes network failure handling in terms of failure maturation, de-maturation and healing.
In an exemplary embodiment, the method learns current status of the DTC in the ECU for distinguishing and classifying plurality of network failure selected from a group comprising network open circuit failure at CAN stub of transmitting ECU, network open circuit failure at main CAN bus, network open circuit failure at CAN stub of receiving ECU, and internal failure in operating tasks within the ECU.
In an exemplary embodiment, the network open circuit failure at the CAN stub of the transmitting ECU is detected by way of detecting the CAN Error-Passive failure in the DTC of the transmitting ECU and the Receive-message Time-out failure in the DTC of the receiving ECU.
In an exemplary embodiment, the network open circuit failure at the main CAN bus is detected by way of detecting the Receive-message Time-out failure in the DTC of the

receiving ECU and absence of CAN Error-Passive failure in the DTC of the transmitting ECU.
In an exemplary embodiment, the network open circuit failure at the CAN stub of the receiving ECU is detected by way of detecting the CAN Error-Passive failure in the DTC of the receiving ECU and absence of any failure in the DTC of the transmitting ECU.
In an exemplary embodiment, the internal failure in operating tasks within the ECU is detected by way of detecting the Transmit-message Time-out failure in the DTC of the transmitting ECU and the receive-message time-out failure in the DTC of the receiving ECU.
In an exemplary embodiment, the CAN Error-Passive failure is detected by the ECU if the ECU enters Error-Passive state and remains in the Error-Passive state continuously for preset configurable time without going to bus-off state.
In an exemplary embodiment, bus-off failure is detected by the ECU if the ECU enters into the bus-off state within the preset configurable time.
In an exemplary embodiment, the ECUs selectively degrades their functionalities depending on criticality and location of the failure.
In an exemplary embodiment, said failure detection method is implemented in all the ECUs in the network.
another exemplary embodiment provides a device for detecting open circuit failure by pin pointing location of the failure in Controller Area Network (CAN) comprises means for monitoring (a) CAN Error-Passive failure, (b) CAN receive-message Time-out failure, and (c) CAN transmit-message Time-out failure, in any combination, in transmitting and receiving Electronic Control Unit (ECUs), and recording corresponding Diagnostic Trouble Code (DTC) in the ECUs; and storage medium within the ECU being adopted for storing the recorded DTC whenever the open circuit failure is detected by the ECU in CAN stub.

In an exemplary embodiment, the means for monitoring the combination of failures is any ECU with CAN interface.
The foregoing summary is illustrative only and is not intended to be in any way limiting. In addition to the illustrative aspects, embodiments, and features described above, further aspects, embodiments, and features will become apparent by reference to the drawings and the following detailed description.
BRIEF DESCRIPTION OF THE ACCOMPANYING DRAWINGS
Figure 1 shows a typical CAN network with six Electronic Control Units (ECUs) and network terminations. The figure also shows three types of network failures.
Figure 2 shows error state transition diagram of a typical CAN node. The figure also shows the criteria for state transitions.
Figure 3 shows the relationship among “Dominant” / “Recessive” state, voltage level at CAN High / CAN Low lines and logic levels for bit value.
Figure 4 shows the structure of ACTIVE ERROR FLAG and PASSIVE ERROR FLAG as per CAN Protocol spec.
Figure 5 shows a trace taken from oscilloscope. The trace shows voltage profile of CAN High and CAN Low lines of a non-terminating ECU which has a transmit message with “Frame Identifier” lower than 80 Hex.
Figure 6 explains the concept of CAN Receive-message Time-out monitoring.
The figures depict embodiments of the disclosure for purposes of illustration only. One skilled in the art will readily recognize from the following description that alternative embodiments of the structures and methods illustrated herein may be employed without departing from the principles of the disclosure described herein.

DETAILED DESCRIPTION
The foregoing has outlined rather broadly the features and technical advantages of the present disclosure in order that the detailed description of the disclosure that follows may be better understood. Additional features and advantages of the disclosure will be described hereinafter which form the subject of the claims of the disclosure. It should be appreciated by those skilled in the art that the conception and specific embodiment disclosed may be readily utilized as a basis for modifying or designing other structures for carrying out the same purposes of the present disclosure. It should also be realized by those skilled in the art that such equivalent constructions do not depart from the spirit and scope of the disclosure as set forth in the appended claims. The novel features which are believed to be characteristic of the disclosure, both as to its organization and method of operation, together with further objects and advantages will be better understood from the following description when considered in connection with the accompanying figures. It is to be expressly understood, however, that each of the figures is provided for the purpose of illustration and description only and is not intended as a definition of the limits of the present disclosure.
Referring now to figure 1, a typical CAN network is illustrated. This CAN network is composed of six Electronic Control Units (ECUs) and these ECUs are connected using twisted pair of CAN wires; one of the pair of wires is called as “CAN High” line and the other wire is called as “CAN Low” line. Out of these six control units, ECU1 and ECU6 are the terminating ECUs of the network. So, both ECU1 and ECU6 contain terminating resistance (120 Ohm) for this CAN network. This means that, when ECU1 (or ECU6) is disconnected from CAN network, the resistance between CAN High and CAN Low lines is 120 Ohm. And if both ECU1 and ECU6 are connected correctly in the network, the equivalent resistance between CAN High and CAN Low lines is 60 Ohm. Let us consider that ECU3 receives CAN messages from ECU1 and ECU5. The arrows in the figure represent these CAN messages which are received by ECU3 from ECU1 and ECU5.

As illustrated further in figure 1, there could be four possible ways in which CAN communication from ECU5 to ECU3 may interrupt:
• Failure type 1: Network open circuit failure has occurred at CAN stub (or branch) of transmitting ECU. This condition is similar to open circuit failure in Location A in referred figure.
• Failure type 2: Network open circuit failure has occurred at the main CAN bus; anywhere between point Y and point X. Where point Y is the location where transmitting ECU stub is connected to main CAN bus and point X is the location where receiving ECU stub is connected to main CAN bus. This condition is similar to open circuit failure in Location B in referred figure.
• Failure type 3: Network open circuit failure has occurred at CAN stub (or branch) of receiving ECU. This condition is similar to open circuit failure in Location C in referred figure.
• Failure type 4: Network is electrically healthy (i.e. no open circuit failure in the network), however, the transmitting ECU (i.e. ECU5) has stopped transmission of CAN messages due to sudden lock of internal operating tasks.
The existing methods fail to discriminate among these four failure types. As a consequence, the network goes to fully degraded mode if failure of any of the above types occurs in the network. This results in lesser reliability for the network operation.
The disclosure proposes methodology to detect and discriminate these four types of network failure as follows:-• When failure type 1 will occur, then transmitting ECU (i.e. ECU5) will detect CAN Error-Passive failure and will set corresponding DTC (Diagnostic Trouble Code). At the same time, receiving ECU (i.e. ECU3) will detect Receive-message Timeout failure and will set corresponding DTC. The presence of both these types of DTCs in the network will represent that failure type 1 has occurred in the network.

• When failure type 2 will occur, then transmitting ECU (i.e. ECU5) will not detect CAN Error-Passive failure. However, receiving ECU (i.e. ECU3) will detect Receive-message Time-out failure and will set corresponding DTC. The presence of Receive-message Time-out DTC and absence of CAN Error-Passive DTC in the network will represent that failure type 2 has occurred in the network.
• When failure type 3 will occur, then transmitting ECU (i.e. ECU5) will not detect CAN Error-Passive failure. However, receiving ECU (i.e. ECU3) will detect CAN Error-Passive failure and will set corresponding DTC. The presence of CAN Error-Passive DTC in receiving ECU and absence of any DTC in transmitting ECU of network will represent that failure type 3 has occurred in the network.
• When failure type 4 will occur, then transmitting ECU (i.e. ECU5) will detect Transmit-message Time-out failure and will set corresponding DTC. At the same time, receiving ECU (i.e. ECU3) will detect Receive-message Time-out failure and will set corresponding DTC. The presence of both these types of DTCs in the network will represent that failure type 4 has occurred in the network.
So, the disclosure employs following three failure detection methods to detect and discriminate four types of network failure:
• CAN Error-Passive failure detection,
• CAN Receive-message Time-out failure detection and
• CAN Transmit-message Time-out failure detection
As per this disclosure, all of these three failure detection methods shall be implemented in all of the ECUs in the network. Each ECU includes storage medium for storing the DTC which helps in identifying the failure types as discussed above. When the ECU learns the presence of types of DTC in the network, then it informs that failure has occurred in the network. Also, it identifies presence of said failure types in the network. Each of the failure detection method is explained in detail below.
CAN Error-Passive failure detection:

As per CAN protocol specification (version 2.0), any CAN controller has three error states:
• Error-Active state: A CAN controller in error-active state takes part in CAN
communication normally and it transmits ACTIVE ERROR FLAG when any communication error is detected by this CAN controller.
• Error-Passive state: A CAN controller in error-passive state takes part in CAN
communication normally; however it transmits PASSIVE ERROR FLAG when any communication error is detected by this CAN controller.
• Bus-off state: A CAN controller in bus-off state is not allowed to take part in CAN
communication and hence the output drivers are switched off.
The transition among these states is governed by two error counts:
• TRASMIT ERROR COUNT
• RECEIVE ERROR COUNT
As the values of these error counts modifies, a CAN controller moves from one error state to the other. CAN protocol specification (version 2.0) specifies all the rules for increment and decrement of these error counts. Following are the list of rules as per the protocol specification:
• Rule 1: When a RECEIVER detects an error, the RECEIVE ERROR COUNT will be increased by 1, except when the detected error was a BIT ERROR during the sending of an ACTIVE ERROR FLAG or an OVERLOAD FLAG.
• Rule 2: When a RECEIVER detects a ’dominant’ bit as the first bit after sending an ERROR FLAG the RECEIVE ERROR COUNT will be increased by 8.
• Rule 3: When a TRANSMITTER sends an ERROR FLAG the TRANSMIT ERROR COUNT is increased by 8.

o Exception 1: If the TRANSMITTER is ’error passive’ and detects an ACKNOWLEDGMENT ERROR because of not detecting a ’dominant’ ACK and does not detect a ’dominant’ bit while sending its PASSIVE ERROR FLAG.
o Exception 2: If the TRANSMITTER sends an ERROR FLAG because a STUFF ERROR occurred during ARBITRATION, and should have been ’recessive’, and has been sent as ’recessive’ but monitored as ’dominant’.
o In exceptions 1 and 2 the TRANSMIT ERROR COUNT is not changed.
• Rule 4: If a TRANSMITTER detects a BIT ERROR while sending an ACTIVE ERROR FLAG or an OVERLOAD FLAG the TRANSMIT ERROR COUNT is increased by 8.
• Rule 5: If a RECEIVER detects a BIT ERROR while sending an ACTIVE ERROR FLAG or an OVERLOAD FLAG the RECEIVE ERROR COUNT is increased by 8.
• Rule 6: Any node tolerates up to 7 consecutive ’dominant’ bits after sending an ACTIVE ERROR FLAG, PASSIVE ERROR FLAG or OVERLOAD FLAG. After detecting the 14th consecutive ’dominant’ bit (in case of an ACTIVE ERROR FLAG or an OVERLOAD FLAG) or after detecting the 8th consecutive ’dominant’ bit following a PASSIVE ERROR FLAG, and after each sequence of additional eight consecutive ’dominant’ bits every TRANSMITTER increases its TRANSMIT ERROR COUNT by 8 and every RECEIVER increases its RECEIVE ERROR COUNT by 8.
• Rule 7: After the successful transmission of a message (getting ACK and no error until END OF FRAME is finished) the TRANSMIT ERROR COUNT is decreased by 1 unless it was already 0.
• Rule 8: After the successful reception of a message (reception without error up to the ACK SLOT and the successful sending of the ACK bit), the RECEIVE

ERROR COUNT is decreased by 1, if it was between 1 and 127. If the RECEIVE ERROR COUNT was 0, it stays 0, and if it was greater than 127, then it will be set to a value between 119 and 127.
• Rule 9: A node is ’error passive’ when the TRANSMIT ERROR COUNT equals or exceeds 128, or when the RECEIVE ERROR COUNT equals or exceeds 128. An error condition letting a node become ’error passive’ causes the node to send an ACTIVE ERROR FLAG.
• Rule 10: A node is ’bus off’ when the TRANSMIT ERROR COUNT is greater than or equal to 256.
• Rule 11: An ’error passive’ node becomes ’error active’ again when both the TRANSMIT ERROR COUNT and the RECEIVE ERROR COUNT are less than or equal to 127.
• Rule 12: A node which is ’bus off’ is permitted to become ’error active’ (no longer ’bus off’) with its error counters both set to 0 after 128 occurrence of 11 consecutive ’recessive’ bits have been monitored on the bus.
As per the above 12 rules from CAN protocol standard, the error state transition diagram is shown in figure 2.
Like any other communication protocol, in CAN communication also binary values (i.e. logic “1” and logic “0”) are communicated among different ECUs. As per CAN protocol specification (version 2.0) and ISO specification (ISO 11898-2), the relationship between these logic levels and actual voltage in the CAN lines is shown in figure 3. Logic level “1” is termed as “recessive” and logic level “0” is termed as “dominant”. So, when ECU transmits logic “1”, it transmits “recessive” bit and the nominal value of voltage in both CAN High and CAN Low lines is 2.5 V. This results in differential voltage Vdiff equal to 0 V. Similarly, when ECU transmits logic “0”, it transmits “dominant” bit and the

nominal value of voltage in CAN High line is 3.5 V and in CAN Low line is 1.5 V. This results in differential voltage Vdiff equal to 2.0 V.
The working of instant technology is now substantiated with the following case studies. However, these case studies should not be construed to limit the scope of the invention.
We can apply the above set of rules in the following case studies:
• Case 1 (Local open circuit for a terminating ECU): Let us consider any terminating ECU in CAN network (i.e. any CAN ECU which contains network termination resistance between its CAN High line and CAN Low line). In figure 1, ECU1 and ECU6 are terminating ECUs. If any terminating ECU in CAN network is disconnected from the CAN network and then the ECU is powered up; then the ECU will try to transmit CAN messages. As the ECU has a terminating resistance between its CAN High and CAN Low lines, the ECU will be able to transmit both “Dominant” and “Recessive” bits. ECU will be able to transmit both types of bits because ECU will be able to meet the voltage levels for “dominant” and “recessive” bits due the presence of 120 Ohm resistance between CAN High and CAN Low lines. So, the ECU is able to transmit and read back correctly all the bits of CAN frame. However, this ECU is disconnected from the main CAN bus, and there is no other ECU who can acknowledge the transmitted CAN frame by making the ACK slot dominant; hence this terminating ECU will detect an “ACKNOWLEDGMENT ERROR”. As per CAN protocol specification, this ECU will retry to transmit the CAN frame and its TRANSMIT ERROR COUNT will increase by 8. This process will repeat until TRANSMIT ERROR COUNT will reach a value greater than 127 and the terminating ECU will reach “error passive” state. Once this ECU reaches “error passive” state, as per Exception 1 of Rule 3, TRANSMIT ERROR COUNT will not increase further and the ECU will continue to remain in “error passive” state. So, from the above reasoning, we can conclude that if any terminating ECU is disconnected from CAN bus and the ECU is powered up then the ECU will continue to remain in “error passive” state.

• Case 2 (Local open circuit for a non-terminating ECU): Let us consider now any non-terminating ECU in CAN network (i.e. any CAN ECU which does not contain network termination resistance between its CAN High line and CAN Low line). In figure 1, ECU2, ECU3, ECU4 and ECU5 are terminating ECUs. As per specification by ISO (i.e. ISO 11898 – 2), the differential internal resistance between CAN High and CAN Low lines of non-terminating ECU is between 10 KOhm to 100 KOhm. Because of this high ohmic differential resistance between CAN High and CAN Low lines, the voltage transition from “dominant” bit to “recessive” bit does not occur fast enough. Now depending on the “frame identifier”, one of the following two scenarios may occur:
o Case 2A (ECU with transmit message ID lower than 80 Hex): Let us consider that the ECU has the following transmit messages with “frame identifer” 70 Hex, 100 Hex and 120 Hex. If this non-terminating ECU in CAN network is disconnected from the CAN network and then this ECU is powered up; then the ECU will try to transmit CAN messages. The CAN message with highest priority will be the first message to be transmitted by the ECU. Out of the three transmit messages, the message with 70 Hex as the “frame identifier” is the highest priority message. So, this ECU will try to transmit the message with “frame identifer” 70 Hex. If 70 Hex is converted into binary, we get the following bit stream B = “00001110000”. So, when this ECU will try to transmit the message with “frame identifier” 70 Hex, it will first transmit “Start of Frame” bit which is logical “0”, followed by the binary stream B. The “Start of Frame” bit along with the four initial bits of stream B will give rise to a bit stream of five consecutive “zero” bits (or “dominant” bits). As per CAN protocol specification (version 2.0), whenever a transmitter ECU detects five consecutive bits of identical value in the bit stream to be transmitted, the transmitter ECU automatically inserts a complementary bit in the actual transmitted bit stream. This is referred as bit stuffing in CAN protocol

specification. Hence, because of bit stuffing technique, this ECU will try to transmit a stuff bit after transmitting five consecutive “zero” bits (or “dominant” bits). As the differential internal resistance between CAN High line and CAN Low line is very high (10 KOhm to 100 KOhm), this ECU will be able to transmit five initial “dominant” bits correctly, but it will take longer time for the voltage profile to become “recessive” bit as the stuff bit. So, this ECU will transmit the stuff bit as “recessive” bit, but it will monitor in the network as “dominant” bit. Hence, stuff bit error will be detected by the ECU. As this ECU starts from “error active” state after power on, ECU will transmit “active error frame” after detecting stuff bit error. As per CAN protocol specification, figure 4 shows the structure of ACTIVE ERROR FLAG. This has six “dominant” bits followed by eight “recessive” bits. After transmission of “active error frame”, ECU will retry to transmit the same message with “frame identifier” 70 Hex, since the ECU failed to transmit the message in the first attempt. However, again the ECU will fail to transmit because of the above. So, every time ECU will try to transmit this message with “frame identifier” 70 Hex, the ECU will transmit total 11 “dominant” bits. 11 “dominant” bits are generated by 1 number of “start of frame” bit followed by 4 number of “dominant” bits from the bit stream B followed by 6 number of “dominant” bits from ACTIVE ERROR FLAG. This situation is exactly similar to the condition stated in exception 2 of rule number 3 among the rule set mentioned above. As per this exception 2, although ECU is transmitting ERROR FLAG after detecting STUFF ERROR, TRANSMIT ERROR COUNT will not be increased. However, another fact is revealed if we have a closer look at the voltage profile in figure 5. The referred figure 5 shows a trace from oscilloscope capturing the voltage profile of CAN High and CAN Low lines of the same ECU considered in this example. The ECU is disconnected from CAN bus and powered up and then the voltage profile is captured in the oscilloscope. It is observed in

the oscilloscope trace that every time ECU will try to transmit this message with “frame identifier” 70 Hex, the ECU will transmit total 11 “dominant” bits. Markers ‘A’, ‘B’ and ‘C’ are placed in the figure where 11 “dominant” bits are seen. However, after 11 “dominant” bits are transmitted, the ECU is not coming to “recessive” level immediately. Due to higher internal differential resistance between CAN High and CAN Low lines, the ECU is taking very longer time to discharge the voltage and come within the band of “recessive” bit voltage. As per ISO standard (ISO 11898-2), the threshold for differential input voltage for “dominant” bit is 0.9 V. This means, until the voltage profile V_diff discharges and reaches below 0.9 V, the ECU will continue to consider the voltage as “dominant” bit. In figure 5, one marker ‘X’ is placed where transmission of 11 “dominant” bits ended by the ECU and another marker ‘Y’ is placed at the point where voltage level for “dominant” bit is still present (i.e. V_diff is just greater than 0.9 V). The time difference between ‘X’ and ‘Y’ markers is 40 micro Sec. As the network communication bit rate is 500 kpbs, one nominal bit time is 2 micro Sec, so this results in 20 dominant bits between marker ‘X’ and ‘Y’. So, although the ECU is actually transmitting only 11 “dominant” bits, however due to higher internal resistance between CAN High and CAN Low lines, the ECU is monitoring 20 more number of “dominant” bits. Now, if we refer back to rule number 6 in the rule set, we can find that after detecting the 14th consecutive “dominant” bit after sending an ACTIVE ERROR FLAG, TRANSMIT ERROR COUNT is increased by 8. Subsequently, again after 8 “dominant” bits, TRANSMIT ERROR COUNT is increased by 8 again. This condition occurs every time ECU tries to transmit message with “Frame Identifier” 70 Hex till ECU reaches “error passive” state. In figure 5, markers ‘D’ and ‘E’ are placed when ECU has reached “error passive” state and ECU is re-trying to transmit the message. As the ECU is in “error passive” state, ECU transmits PASSIVE ERROR FLAG.

Figure 4 shows the structure of PASSIVE ERROR FLAG as per CAN protocol spec and we can find that all bits of PASSIVE ERROR FLAG are “recessive” bits, hence ECU transmits only 5 “dominant” bits. So, markers ‘D’ and ‘E’ shows that ECU has transmitted 5 “dominant” bits in “error passive” state. Again, due to higher internal differential resistance between CAN High and CAN Low lines, the ECU is not coming to “recessive” level immediately after transmission of 5 “dominant” bits, ECU is taking very longer time to discharge the voltage. In figure 5, marker ‘M’ is placed where transmission of 5 “dominant” bits ended by the ECU and another marker ‘N’ is placed at the point where voltage level for “dominant” bit is still present (i.e. V_diff is just greater than 0.9 V). The time difference between ‘M’ and ‘N’ markers is 40 micro Sec. So this results in 20 dominant bits between markers ‘M’ and ‘N’. So, although the ECU is actually transmitting only 5 “dominant” bits, however due to higher internal resistance between CAN High and CAN Low lines, the ECU is monitoring 20 more number of “dominant” bits. Now, if we refer back to rule number 6 in the rule set, we can find that after detecting the 8th consecutive “dominant” bit after sending a PASSIVE ERROR FLAG, TRANSMIT ERROR COUNT is increased by 8. Subsequently, again after 8 “dominant” bits, TRANSMIT ERROR COUNT is increased by 8 again. This condition occurs every time ECU tries to transmit message with “Frame Identifier” 70 Hex till ECU reaches “bus-off” state. So, we find that if any non-terminating ECU is disconnected from the CAN bus and it tries to transmit a message for which it detects STUFF ERROR, the ECU will enter into “bus-off” state. So, the ECU will detect STUFF ERROR, if there are five consecutive “dominant” bits in the transmit CAN message. As the first bit of CAN message is always “dominant” bit, the STUFF ERROR will always take place if first four bits of “Frame Identifier” are “dominant” bits. This observation will help to derive following condition. The minimum value of “Frame Identifier” which

does not have four consecutive “dominant” bits is B = “00010000000”. This bit stream value of B when converted to Hex, gives value of 80 Hex. So, we can conclude that if any non-terminating ECU is disconnected from CAN bus and the ECU tries to transmit any “Frame Identifier” with value less than 80 Hex, then the ECU will always go “bus-off” state.
o Case 2B (ECU with transmit message ID greater than 80 Hex): Having made the above conclusion, now, let us consider that the ECU does not have any message with “Frame Identifier” less than 80 Hex. So, ECU has the following transmit messages with “frame identifer” 170 Hex, 180 Hex and 190 Hex. If this non-terminating ECU in CAN network is disconnected from the CAN network and then this ECU is powered up; then the ECU will try to transmit CAN messages. The CAN message with highest priority will be the first message to be transmitted by the ECU. Out of the three transmit messages, the message with 170 Hex as the “frame identifier” is the highest priority message. So, this ECU will try to transmit the message with “frame identifer” 170 Hex. If 170 Hex is converted into binary, we get the following bit stream B = “00101110000”. So, when this ECU will try to transmit the message with “frame identifier” 170 Hex, it will first transmit “Start of Frame” bit which is logical “0”, followed by the binary stream B. So, this ECU will transmit three consecutive logical “0” or “dominant” bits and then it will try to transmit logical “1” or “recessive” bit. Again, due to higher internal differential resistance between CAN High and CAN Low lines, the ECU will not be able to transmit “recessive” bit immediately after transmission of 3 “dominant” bits, because ECU will take very longer time to discharge the voltage. So, ECU will transmit “recessive” bit but ECU will monitor “dominant” bit in the bus. Hence, ECU will loose arbitration and ECU will immediately stop transmission of CAN message and ECU will go to receive mode. In receive mode when ECU detects STUFF ERROR, RECEIVE ERROR COUNT is increased by 1 as per rule number 1 from

above rule set. This happens repetitively and the ECU reaches “error passive” state. As the ECU always enters into receive mode, its TRANSMIT ERROR COUNT will never increase. It is to be noted that an ECU will go to “bus-off” only if its TRANSMIT ERROR COUNT is greater than 255. Because of this reason, ECU will remain in “error passive” state only; ECU will never go to “bus-off” state.
• Case 3 (Short circuit in the CAN network): Let us now consider any ECU in
CAN network irrespective of whether it is terminating ECU or non-terminating
ECU. If there is a short circuit between CAN High and CAN Low lines, then the
ECU is powered up and the ECU will try to transmit CAN messages. But due to
short circuit between CAN High and CAN Low lines, the differential voltage
between CAN High and CAN Low lines will be always zero (i.e. Vdiff = CAN
High – CAN Low = 0). Now the same explanation of case 2A will be applicable.
ECU will detect STUFF ERROR and applying rule 6, TRANSMIT ERROR
COUNT of ECU will increase. This will happen until ECU will reach “bus-off”
state. As short circuit is a global failure, so if there is a short circuit failure in any
location, all ECUs will go to “bus-off” state.
From the above case studies, it is possible to derive the following:
• If there a local open circuit in CAN wires for a terminating ECU, the ECU will go to “error-passive” state and remain there.
• If there a local open circuit in CAN wires for a non-terminating ECU
o If the ECU does not transmit any CAN message with “Frame Identifier” less than 80 Hex, then the ECU will go to “error-passive” state and remain there.
o If the ECU transmits at least one CAN message with “Frame Identifier” less than 80 Hex, then the ECU will go to “bus-off” state and remain there.

• If there a short circuit in CAN wires, then all ECUs will go to “bus-off” state and
remain there.
Using the above derivations, we propose the following failure detection strategy.
Referring now to figure 2, illustrates the error state diagram of a CAN node. If the ECU enters error-passive state and remains in error-passive state continuously for TCanErrorPassive (configurable time) without going to bus-off state then error-passive failure shall be detected by the ECU. This detection of error-passive failure will indicate that there is a local open circuit failure in the CAN lines of the ECU.
But if ECU goes to bus-off state within this TCanErrorPassive time, then only bus-off failure shall be detected by the ECU, error-passive failure shall not be detected. ECU shall follow ECU behaviour during bus-off failure. This may happen when there is a short circuit failure in CAN bus, ECU will come to “error-passive” state and then immediately ECU will move to “bus-off” state.
TCanErrorPassive is the de-bounce time to ascertain error-passive failure. TCanErrorPassive shall be configurable time. Default value of TCanErrorPassive shall be 100 ms.
ECUs shall start CAN error-passive monitoring only after 500ms (configurable) of logical detection of IGN on. ECUs shall stop CAN error-passive monitoring within 10ms (configurable) of logical detection of IGN off.
If an error-passive failure is detected by an ECU, the following shall be its behavior:-• Then an active DTC shall be raised to record this failure (local open circuit failure in CAN lines). The status of the active DTC shall signify that actual failure is present.
• ECU shall use the default values for the signals for the received message(s).

• Depending on the application, ECU may go to degraded functionality mode and turn on its warning lamp in instrument cluster to inform its CAN open circuit condition to driver.
• CAN message monitoring (both transmit-message time-out monitoring and receive-message time-out monitoring) shall be switched off. In other words, after error-passive failure is asserted, ECUs shall not monitor receive-messages from the partner ECUs and transmit-messages of itself. This will ensure that in the case of local open circuit failure, only the corresponding DTC will be logged by the ECU.
After error-passive failure is asserted and corresponding error-passive active DTC is logged, ECU may either enter bus-off state or error-active state in the same ignition cycle. Then ECU shall behave as per following:-• If ECU enters bus-off state, then bus-off failure shall be detected and ECU shall follow ECU behaviour during bus-off failure. Error-passive failure shall not be cleared. Both the failures (bus-off and error-passive) shall be detected by the ECU.
• If ECU enters error-active state, and remains in the error-active state for 1000 ms
(configurable), only then error-passive failure shall be cleared. This shall be
considered as successful recovery from error-passive failure.
After successful recovery from error-passive failure (or CAN open circuit failure) after the open circuit failure is cleared, ECU shall behave as follows:-• The error-passive DTC shall be memorized in ECUs non-volatile memory for ‘X’ number of driving cycles. The status of the memorized DTC shall classify whether the failure was detected in the same driving cycle or previous driving cycle. ‘X’ is a configurable parameter and typically it shall be 50.
• ECU shall start using the received signal values of the message(s).

• Depending on the application, ECU may come back to full functionality mode and turn off the warning lamp in instrument cluster to inform its healthy condition to driver.
• CAN message monitoring (both transmit-message time-out monitoring and receive-message time-out monitoring) shall be switched on. ECUs shall start monitoring receive-messages from the partner ECUs as well as transmit messages from itself after successful recovery from error-passive failure.
From the above explanation it is possible to conclude that detection of CAN error-passive failure as per strategy can be used to detect local open circuit failure in network stubs (or network branches).
CAN receive-message Time-out failure detection:
The CAN receive-message time-out failure shall be detected as follows:-For each ECU in the network
• For each message received by that ECU
o Record the ‘inter-message time period’ between sequential receptions of this message.
o If the ‘inter-message time period’ exceeds a configurable threshold (the failure detection threshold), then receive-message time out failure shall be detected by the receiver ECU against the transmitting ECU. The failure detection threshold shall be set by default to the time-out value of the respective frame. This value shall be 500ms by default.
If receive-message time out failure is detected by an ECU:-• Then an active DTC shall be raised to record this failure (receive-message timeout failure) by the receiver ECU against the transmitting ECU. The status of the active DTC shall signify that actual failure is present.

• Receive-message time out DTC shall be raised against ECUs and not against individual messages. The receive-message time-out DTC has to be raised if message time out failure is asserted for at least one receive-message from a partner ECU.
• ECU shall use the default values for the signals of the timed out message(s).
• Depending on the application, ECU may go to degraded functionality mode and turn on its warning lamp in instrument cluster to inform its poor condition to user.
The CAN receive-message time-out failure shall be cleared if the message reception resumes properly for a configurable period of time. The default value of this failure clearing time shall be 500ms.
If the receive-message time out failure is cleared:-• The time out DTC shall be memorized for ‘X’ number of driving cycles. The status of the memorized DTC shall classify whether the failure was detected in same driving cycle or previous driving cycle. ‘X’ is a configurable parameter and typically it shall be 50.
• ECU shall start using the received signal values of the message(s).
• Depending on the application, ECU may come back to full functionality mode and turn off the warning lamp in instrument cluster to inform its healthy condition to user.
The above strategy for CAN receive-message failure monitoring is explained in figure 6.
CAN transmit-message Time-out failure detection:
In the case where an ECU is not able to transmit any CAN message when the ECU is connected correctly in a properly terminated CAN network, due to any unexpected reason (e.g. arbitration loss, internal software lock, etc), the ECU which is the transmitter

of the particular message/frame in the network shall be able to identify the interruption in transmission and recognize this as a failure.
All ECUs in the network shall employ transmit-message monitoring by implementing transmit-message timeout detection as explained below.
For each ECU on the network
• For each message transmitted by that ECU
o Record the ‘inter-message time period’ between sequential transmissions of this message.
o If the ‘inter-message time period’ exceeds a configurable threshold (the failure detection threshold), then transmit-message time out failure shall be detected by the transmitting ECU against itself. The failure detection threshold shall be set by default to the time-out value of the respective frame. This value shall be 500ms by default
If transmit-message time out failure is detected by an ECU:-• Then an active DTC shall be raised to record this failure (transmit-message timeout failure) by the transmitting ECU against itself. The status of the active DTC shall signify that actual failure is present. Refer TML diagnostic spec for details on DTC status.
• Transmit-message time out DTC shall be raised against ECUs and not against individual messages. The transmit-message time-out DTC has to be raised if message time out failure is asserted for at least one transmit-message by the ECU.
• Transmitting ECU shall understand that other ECUs which are expected receiver of the message, has detected receive-message time out against the transmitting ECU and started using the default values for the signals of the timed out message(s) and has gone to degraded functionality mode depending on application.

The CAN transmit-message time-out failure shall be cleared if the message transmission resumes properly for a configurable period of time. The default value of this failure clearing time shall be 500ms.
If the transmit-message time out failure is cleared:-• The time out DTC shall be memorized for ‘X’ number of driving cycles. The status of the memorized DTC shall classify whether the failure was detected in same driving cycle or previous driving cycle. ‘X’ is a configurable parameter and typically it shall be 50.
• Transmitting ECU shall understand that other ECUs which are expected receivers of the message have started using the received signal values of the message(s) and have come back to full functionality mode depending on application.
The three failure detection methods are explained above. The disclosure also explains how these three failure detection methods can be used to detect and discriminate four types of network failures. The network will behave differently for each of the four failure types. Thus it will be possible to distinguish and discriminate all of the four failure types. Table 1 summarizes the difference in network failure detection under each failure.
As the ECUs are able to detect and distinguish each of the four failure type, ECU is now able to selectively degrade its functionalities at the event of each failure. If ECU is not able to distinguish these failures then ECU will degrade its all functions irrespective of the failure type which has occurred. This increases the average down-time for the whole set of functionalities of the ECU. Instant technology outlined in the disclosure proposes to selectively degrade different functionalities of the ECU based on the criticality of the four failure types so that average down-time of the ECU functionalities will reduce.

Table 1: Network failure detection in the event of four different failure types with example

Failure type Description of failure condition Failure detection by the network Example of failure condition
and failure detection (with reference to figure 1)
Type 1 Network local open circuit failure at CAN stub (or branch) of transmitting ECU. Transmitting ECU will detect CAN error-passive failure and receiving ECU will detect CAN receive-message time-out failure. If there is a local open circuit failure in Location A, then ECU5 will detect CAN error-passive failure and ECU3 will detect CAN receive-message time-out failure.
Type 2 Network global open circuit failure at the main CAN bus; the location global open circuit failure is within the segment of main CAN bus between the points where the transmitting ECU stub is connected to main CAN bus and receiving ECU stub is connected to main CAN bus. Only receiving ECU will detect CAN receive-message time-out failure. Transmitting ECU will not detect any CAN failure. If there is a global open circuit failure in Location B (which is within the segment of main CAN bus between points X and Y), then only ECU3 will detect CAN receive-message time-out failure. ECU5 will not detect any CAN failure.
Type 3 Network local open circuit failure at CAN stub (or branch) of receiving ECU. Only receiving ECU will detect CAN error-passive failure. Transmitting ECU will not detect any CAN failure. If there is a local open circuit failure in Location C, then only ECU3 will detect CAN error-passive failure. ECU1 and ECU3 will not detect any CAN failure.
Type 4 Network is electrically healthy (i.e. no open circuit failure in the network), however, the transmitting ECU has stopped transmission of CAN messages due to sudden lock of internal operating tasks. Transmitting ECU will detect transmit-message time-out failure and receiving ECU will detect receive-message time-out failure. If ECU5 has stopped transmission of CAN messages due to sudden lock of internal operating tasks in ECU5, then ECU5 will detect transmit-message time-out failure and ECU3 will detect receive-message time-out failure.
While considerable emphasis has been placed herein on the particular features of this disclosure, it will be appreciated that various modifications can be made, and that many changes can be made in the preferred embodiment without departing from the principle of the disclosure. These and other modifications in the nature of the disclosure or the preferred embodiments will be apparent to those skilled in the art from the disclosure herein, whereby it is to be distinctly understood that the foregoing descriptive matter is to be interpreted merely as illustrative of the disclosure and not as a limitation.

We claim:
1. A method of detecting open circuit failure by pin pointing location of the failure in Controller Area Network (CAN) comprising acts of monitoring (a) CAN Error-Passive failure, (b) CAN receive-message Time-out failure, and (c) CAN transmit-message Time-out failure, in any combination, in transmitting and receiving Electronic Control Units (ECUs), and recording corresponding Diagnostic Trouble Code (DTC) in the ECU to detect the open circuit failure.
2. The method as claimed in claim 1, wherein the method learns current status of the DTC in the ECU for distinguishing and classifying plurality of network failure selected from a group comprising network open circuit failure at CAN stub of transmitting ECU, network open circuit failure at main CAN bus, network open circuit failure at CAN stub of receiving ECU, and internal failure in operating tasks within the ECU.
3. The method as claimed in claim 2, wherein the network open circuit failure at the CAN stub of the transmitting ECU is detected by way of detecting the CAN Error-Passive failure in the DTC of the transmitting ECU and the Receive-message Time-out failure in the DTC of the receiving ECU.
4. The method as claimed in claim 2, wherein the network open circuit failure at the main CAN bus is detected by way of detecting the Receive-message Time-out failure in the DTC of the receiving ECU and absence of CAN Error-Passive failure in the DTC of the transmitting ECU.
5. The method as claimed in claim 2, wherein the network open circuit failure at the CAN stub of the receiving ECU is detected by way of detecting the CAN Error-Passive failure in the DTC of the receiving ECU and absence of any failure in the DTC of the transmitting ECU.
6. The method as claimed in claim 2, wherein the internal failure in operating tasks within the ECU is detected by way of detecting the Transmit-message Time-out failure in the

DTC of the transmitting ECU and the receive-message time-out failure in the DTC of the receiving ECU.
7. The method as claimed in claim 1, wherein the CAN Error-Passive failure is detected by the ECU if the ECU enters Error-Passive state and remains in the Error-Passive state continuously for preset configurable time without going to bus-off state.
8. The method as claimed in claim 7 wherein bus-off failure is detected by the ECU if the ECU enters into the bus-off state within the preset configurable time.
9. The method as claimed in claim 1, wherein the ECUs selectively degrade their functionalities depending on criticality and location of the failure.
10. The method as claimed in claim 1, wherein said failure detection method is implemented in all the ECUs in the network.
11. A device for detecting open circuit failure by pin pointing location of the failure in Controller Area Network (CAN) comprises
i. means for monitoring (a) CAN Error-Passive failure, (b) CAN receive-message Time-out failure; and (c) CAN transmit-message Time-out failure, in any combination, in transmitting and receiving Electronic Control Unit (ECUs), and recording corresponding Diagnostic Trouble Code (DTC) in the ECUs; and
ii. storage medium within the ECU being adopted for storing the recorded DTC whenever the open circuit failure is detected by the ECU in CAN stub.
12. The device as claimed in claim 11, wherein the means for monitoring the combination
of failures is any ECU with CAN interface.