Association Model-Based Intermittent Connection Fault Diagnosis for Controller Area Networks

Abstract

Controller Area Networks (CANs) play an important role in many safety-critical industrial systems, which places high demands on their reliability performance. However, the intermittent connection (IC) of network cables, a random and transient connectivity problem, is a common but hard troubleshooting fault that can cause network performance degradation, system-level failures, and even safety issues. Therefore, to ensure the reliability of CANs, a fault symptom association model-based IC fault diagnosis method is proposed. Firstly, the symptoms are defined by examining the error records, and the domains of the symptoms are derived to represent the causal relationship between the fault locations and the symptoms. Secondly, the fault probability for each location is calculated by minimizing the difference between the symptom probabilities calculated from the count information and those fitted by the total probability formula. Then, the fault symptom association model is designed to synthesize the causal and the probabilistic diagnostic information. Finally, a model-based maximal contribution diagnosis algorithm is developed to locate the IC faults. Experimental results of three case studies show that the proposed method can accurately and efficiently identify various IC fault location scenarios in networks.

1. Introduction

Controller area networks (CANs), as field buses that effectively support distributed and real-time control, have been widely applied in many safety-critical networked automation applications, such as DeviceNet-based manufacturing systems, whose underlining physical and data-link layers use the CAN protocol [1]. However, in practice, numerous factors, such as mechanical vibration, environmental disturbances, and inappropriate human intervention, can cause faults in the CAN. Among the various faults in the networks, an intermittent fault (IF) is a difficult troubleshooting problem that recurs within a certain period of time at the same location [2]. The frequency of IFs is usually approximately 10 to 30 times that of permanent faults [3,4]. Intermittent connection (IC) faults, which are the focus of this paper, are a cable connection type of IF in which network cables randomly disconnect for a short duration; faults of this type have been reported in various industries, such as manufacturing and automotive [5]. For example, IC faults are reportedly one of the root causes of No Fault Found (NFF) events [6], which account for 21–70% of failure events in avionics and automotive electronic systems [5,7,8]. According to a survey conducted in a major automobile manufacturing plant, nearly 54% of network system downtime is caused by cable damage, wear, and loose connections [9]. On an automotive manufacturing line, IC faults often occur on trunk cables when the network is mounted in a vibration environment or on repetitively moving equipment, and IC faults on drop cables are also common since most system reconfigurations and maintenance actions involve disassembling and reconnecting the drop cables in the network, which are prone to wear and improper maintenance. During the early stage, an IC fault will cause transmission delay or message loss via random interruption of bus communication, leading to deterioration in network performance. In severe cases, IC faults can cause nodes to detach from the network, which can lead to the shutdown of safety-critical systems, increase network maintenance costs, and even cause safety hazards [10]. For example, IC faults have been reported as one of the major threats to customer satisfaction and automaker cost control [5,6,11,12]. The impacts of cable connection problems on the costs incurred by aviation system manufacturers have also been reported [13,14].

Unfortunately, IC faults are hidden and difficult to diagnose. First, since the CAN nodes share the bus medium, the cable disconnections resulting from IC faults affect the entire bus, making it challenging to establish a direct mapping between the fault location and the affected nodes. Second, IC faults appear randomly and cannot be reproduced when the system is shut down or idle. Therefore, online localization of IC faults before they cause further system-level damage is an important challenge in CAN-based industrial systems that urgently needs to be addressed.

In the literature, the fault diagnosis of electronic circuits has been widely studied. He et al. proposed an analog circuit fault diagnosis method in which cross-wavelet singular entropy is used for fault feature extraction and the optimal features obtained through parametric t-distributed stochastic neighbor embedding are entered into a support vector machine classifier to locate faulty components [15]. He et al. proposed an analog circuit component fault diagnosis method using the time–frequency features of fault signals and a vector-valued regularized kernel function approximation classification algorithm [16]. Zhang et al. proposed a multifault diagnosis method for a lithium-ion battery pack based on a voltage difference analysis technique, where the diagnosable faults included internal resistance faults and connection faults [17]. However, these methods are primarily oriented toward electronic component faults and do not apply to circuit line intermittent faults.

In recent years, an extensive literature related to IF diagnosis has been published. Some studies have focused on the detection and recognition of IFs [4,18,19,20,21,22,23,24,25,26]; for example, Fang et al. proposed a density peak clustering-based IF recognition method for analog circuits [4]. Zhang et al. proposed a residual evaluation model to detect sensor IFs [20]. Cai et al. proposed a dynamic Bayesian network-based fault diagnosis method for recognizing transient faults, IFs, and permanent faults in electronic systems [22]. Gouda et al. proposed a one-shot likelihood ratio test for evaluating the IF status of individual sensor nodes in wireless sensor networks [24]. However, a practical procedure for IF localization was not described in the aforementioned studies.

Studies have also been conducted on locating IFs in several industrial systems. For instance, Yu et al. developed an IF detection and isolation method for a steer-by-wire system based on a composite degradation model [27]. Yaramasu et al. proposed an intermittent wiring fault location method for aircraft power distribution systems based on the estimation of load circuit model coefficients and parameters [28]. Huang et al. proposed an improved deep forest classifier to locate IFs in analog circuits [29]. Furse et al. utilized spread spectrum time-domain reflectometry and sequence time-domain reflectometry to locate intermittent wiring faults in aircraft power circuits [30,31]. Jiang et al. developed a support vector machine-based IF location method for aircraft fuel systems [32]. Alamuti et al. proposed a method for locating intermittent arcing faults in low-voltage radial feeders based on time-domain formulations [33]. Farughian et al. proposed an intermittent earth fault passage indication method to locate the faulty segment in a compensated distribution network [34]. Li et al. presented a data-driven method based on dynamic principal component analysis for diagnosing IFs in spacecraft gyroscopes [35]. Li et al. proposed a fault diagnosis method based on dynamic analysis for electronic systems with transient faults and IFs [36]. Yan et al. proposed an IF detection and isolation method for linear stochastic systems [37]. Song et al. developed a probabilistic diagnosis algorithm to locate intermittently faulty nodes in a randomly generated network [38]. However, the methods proposed in [27,28,29,30,31,32,33,34,35,36,37,38] are applicable only to specific devices or ad hoc systems and are not suitable for CANs.

Various aspects of CANs have been studied. For example, in fault diagnosis-related studies, Kelkar et al. devised an adaptive fault diagnosis algorithm for CANs (AFDCAN), which uses a definite number of testing rounds and messages to detect faulty nodes in a CAN [39,40], and similar work was also reported by Nath et al. [41]. Yang et al. presented an anomaly detection method for detecting persistent anomalies in CAN buses, such as terminal resistance loss and cable degradation [42]. Hassen et al. located a wire fault in a CAN bus based on an orthogonal multitone time-domain reflectometry method [43]. Hu et al. implemented the online diagnosis of node faults and permanent communication link faults in a CAN based on a network management program [44]. Gao et al. determined fault duration based on the affected message time intervals and identified the fault type by monitoring the fault features [45]. However, the methods developed in [39,40,41,42,43,44,45] can address only permanent faults and are not suitable for diagnosing IFs in a CAN.

Several studies have also analyzed the CAN network performance under IFs, such as electrical fast transients (EFTs) and electromagnetic interference (EMI). For example, Pohren et al. analyzed the performance of the CAN with a Flexible Data (CAN-FD) protocol using the EFT injection method [46]. Roque et al. developed a runtime fault diagnostic mechanism to monitor the performance degradation of in-vehicle networks using an early fault modeling approach [47]. Nevertheless, localization techniques for cable IC faults are not addressed in these methods.

Recently, several studies have been conducted on the cable IC problem for CANs. Lei et al. proposed an early IC fault detection method based on a ranked probability control chart, which is effective at monitoring the shifting of error distributions [48]. However, identification of the IC fault location was not addressed. Lei and Djurdjanovic developed a graph-based IC fault location method [49]. Lei et al. also developed a drop cable IC fault location method using the confidence intervals of the parameters of a generalized zero-inflated Poisson model [50]. However, the methods proposed in [49,50] are constrained to IC faults on drop cables in the network. To localize IC faults on both drop and trunk cables, Lei et al. proposed a two-step IC fault location method based on the statistical significance of the error event model parameters [51]. However, this approach is not robust since it relies on analog information analysis based on physical layer information. In addition, this approach can only address a single trunk cable IC fault in the network. Subsequently, IC fault diagnosis methods based on the data link layer were studied. Zhang et al. proposed an IC fault location method based on data link layer error information that uses a concurrent localization algorithm to find faulty links [52]. Zhang et al. proposed a tree-based minimal cost diagnosis algorithm to diagnose IC faults [53]. However, the diagnostic strategies of [52,53] have poor discriminability and can only locate IC faults on up to two trunk cables in the network. In addition, these knowledge-based approaches cannot precisely quantify the probability of fault occurrence for every cable. Wang et al. proposed an IC fault diagnosis approach for CANs using a divide-and-conquer strategy [54]. However, this method requires that the cable connectors of all nodes be accessible to sensors, which is not always feasible in engineering environments. Furthermore, this method generally requires repeated diagnosis to locate all IC faults.

Table 1. Summary of related work.

Reference	Main Approach	Research Gap
[15,16,17]	Fault diagnosis methods for electronic circuits	Only permanent component faults are considered, not IFs.
[4,18,19,20,21,22,23,24,25,26]	IF detection and recognition methods for electrical systems	IF localization is not addressed.
[27,28,29,30,31,32,33,34,35,36,37,38]	IF localization methods for electrical systems	Specialized for specific systems, not applicable to IF diagnosis for CANs.
[39,40,41,42,43,44,45]	Fault diagnosis methods for CANs	Only permanent faults are considered, not IFs.
[46,47]	Analysis of IF-induced performance anomalies for CANs	IF localization is not addressed, and cable faults are not considered.
[48]	IC fault detection method for CANs	IC fault localization is not addressed.
[49,50]	Physical layer-based location methods for drop cable IC faults in CANs	IC faults on trunk cables cannot be located.
[51]	Physical layer-based IC fault location methods for CANs	Robustness is poor, and only one trunk cable IC fault can be located.
[52,53]	Data link layer-based IC fault location methods for CANs	Only up to two trunk cable IC faults can be located, and the fault probability for every cable cannot be quantified.
[54]	Indirect method of locating IC faults in complex topology CANs	Multiple trunk cable IC faults can be located, but it requires repeated diagnosis.
This work	Direct method of locating IC faults in CANs	(Covered gap) Locate multiple trunk cable IC faults accurately without need for repeated diagnosis.

presents a summary of the main aspects of the problem addressed in the literature and the corresponding research gaps. As shown in Table 1, even methods designed specifically to address the IC fault localization problem for CANs [49,50,51,52,53,54] still have the following drawbacks: First, existing methods cannot handle general IC location scenarios, such as cases in which multiple trunk cables suffer from IC faults, which are prone to occur in practical engineering environments. Second, due to the lack of precise quantification of the fault probability for every cable, the diagnostic accuracy of the existing methods is limited; i.e., the cable condition between the two most marginal trunk faults cannot be identified. Third, existing methods require repeated diagnosis for complete identification of multiple IC faults. In order to overcome the diagnosability and diagnostic accuracy limitations of existing methods without adjusting the sensor positions, as well as to overcome the diagnostic efficiency limitation of the existing methods that require repetitive diagnosis, there is a particular need to develop a generalized IC fault diagnosis method to accurately diagnose complex scenarios, such as multiple trunk cable IC faults, without need for repeated diagnosis, which is the gap covered by the present work, as highlighted in Table 1.

To this end, this paper proposes an IC fault diagnosis method for CANs based on fault symptom association models. The advantages of the proposed method are as follows:

• The proposed diagnostic method has wider applicability to fault conditions as it can completely locate IC faults in complex location scenarios that cannot be handled by existing methods, such as IC faults on multiple trunk cables.
• Fault symptom association models are developed for precisely quantifying the fault probability for each cable and the causality of each cable fault with respect to the recorded symptoms, thereby ensuring higher diagnostic accuracy than that of existing methods.
• The proposed framework has higher diagnostic efficiency as it can produce the accurate result in a single diagnostic process, whereas the existing methods require repeated diagnosis of several areas in the network.

The results of this work will facilitate the development of an online IC fault diagnostic tool that can be attached to CAN-based systems to diagnose IC fault-induced system failures and ultimately improve system reliability.

The remainder of this paper is organized as follows: Section 2 introduces the characteristics of IC faults and presents the problem definition. The IC fault diagnosis methodology is proposed in Section 3, including the symptoms and their domains, the fault symptom association models, and the model-based maximal contribution diagnosis algorithm. Section 4 describes the construction of a testbed and reports case studies conducted to demonstrate the effectiveness of the proposed method. The proposed method is compared with the existing IC fault diagnosis methods in Section 5 to show the advantages and improvements of the proposed method. Section 6 concludes the paper and discusses future work.

2. Preliminaries

In this section, the CAN fault-handling mechanism and the categories of IC faults are introduced, and then the problems faced in this work are presented.

2.1. CAN Fault-Handling Mechanism

A CAN is a shared-medium access network that uses a two-wire differential signal, which has two logical states: recessive and dominant [55]. According to the bit-stuffing mechanism in the CAN protocol, after five identical logical bits appear, an opposite bit is automatically inserted [56]. Five types of errors can be detected: bit error, stuff error, CRC error, form error, and acknowledgment error. As soon as an error condition is detected, the corresponding node sends an error frame that contains six successive dominant bits, thus violating the bit-stuffing mechanism. Hence, other nodes in the network can learn of the error and send their own error frames to interrupt the current transmission. Communication will resume when the bus is idle again [55].

2.2. Introduction to IC Faults

The IC fault studied in this paper is the phenomenon of short-time cable disconnection. At the location where an IC fault occurs, this open-circuit fault will turn the dominant bit into the recessive bit. For the whole bus, different IC fault locations will result in different error patterns on the bus. Therefore, we classify IC faults into two categories based on location: a local IC fault occurs on the drop cable, and a trunk IC fault occurs on the trunk cable, as shown in Figure 1. To facilitate analysis, we assume in this section that node 1 is the sending node. The details of the possible error patterns on the bus are introduced as follows:

2.2.1. Local IC Faults

There are two scenarios in which a local IC fault may occur. As shown in Figure 1, scenario A is the case in which an IC fault occurs on the drop cable of the sending node, i.e., node 1. In this case, the data transmitted on the bus are different from those sent by node 1. Thus, all nodes will detect the error and send error frames simultaneously.

In scenario B, an IC fault occurs on the drop cable of a nonsending node, e.g., node 4. In this case, the data transmitted on the bus are the same as those sent by node 1. Since only node 4 is affected by the IC fault, only the data received by node 4 are different from the data transmitted on the bus. Thus, node 4 will be the first to send an error frame to interrupt transmission.

2.2.2. Trunk IC Faults

In scenario C, as shown in Figure 1, a trunk IC fault divides the bus into left and right segments. Due to the disruption caused by the trunk IC fault, only the data transmitted on the bus to the left of the IC fault are the same as those sent by node 1, whereas the data transmitted on the bus to the right of the IC fault are different from those sent by node 1. Hence, the nodes connected to the bus to the right of the IC fault, i.e., node 3 and node 4, will be the first to send error frames to interrupt transmission.

2.3. Problem Definition

It is easy to determine whether an IC fault has occurred in the network by detecting an error frame. However, locating the corresponding IC fault is quite difficult since the diagnostic information embedded in the error frame is limited. Therefore, to diagnose IC faults, the following problems must be addressed:

(1)

Given a sequence of error frames, how to describe the error patterns to enable identification of the IC fault category?

(2)

How to determine the range of possible IC faults implied by each error pattern? In addition, how to precisely quantify the possibility of each IC fault?

(3)

How to filter the exact IC fault location from the fault range without misdiagnosis and missed diagnosis?

Four assumptions are adopted in this paper: (1) The links connecting the data collection points to the network are reliable. (2) The occurrences of IC faults are independent from each other and persist over time. (3) Each node sends a finite amount of I/O status data frames. (4) The network configuration remains unchanged during system operation.

3. Methodology

In this section, a fault symptom association model-based IC fault diagnosis method is proposed to identify various fault location scenarios in a CAN. The basic idea of this methodology is that by building fault symptom association models to quantitatively describe the fault probability for each cable link and the causality for each cable link with respect to the error records, it becomes possible to locate all IC faults by finding the link set that can best explain the error records in accordance with the fault probability.

The overall framework of the proposed method is shown in Figure 2. When a set of errors is recorded, the error records are analyzed to obtain the symptoms for all nodes. Then, the domains of the symptoms can be derived based on the network topology. Next, by using the count information of different symptoms, the parameters of fault symptom association models (FSAMs) for local (FSAM_Loc) and trunk (FSAM_Trk) IC faults, including the occurrence probability of each fault in the domain and the causality of each fault with respect to each symptom, can be calculated separately based on the total probability formula. Finally, based on the contribution rankings obtained from the two FSAMs, all IC faults can be accurately localized by applying a model-based maximum contribution diagnosis algorithm (MMCDA). The details of the proposed method are introduced as follows:

3.1. Collection and Analysis of Error Records

To retrieve the important information of each error, i.e., its sending node address and the difference between it and the correct data frame, the field programmable gate array (FPGA)-based collection hardware is deployed at both ends of the bus, as represented by collection points $C_1$ and $C_2$ in Figure 3. Once an error frame is detected, i.e., a frame with six successive dominant bits, the collection hardware is triggered to collect an error record. An example of an error record collected at a collection point is shown in Figure 4a, which includes the interrupted data frame and the error frame.

As illustrated in Figure 4a, the error frame may start at a dominant bit of the interrupted data frame; consequently, the end of the interrupted data frame cannot be identified, making it difficult to extract the interrupted data frame. Therefore, we define the logical sequence before the first bit of the sequence of successive dominant bits as the detected data, which form part of the interrupted data frame. The node address of each error record can be obtained by reading the address segment of the detected data. Additionally, the correctly transmitted data frame is recorded by a CAN analyzer, as shown in Figure 4b, in which the logical sequence corresponding to the detected data is defined as the reference data for further symptom analysis.

3.2. Generation of Symptoms

Once the node address of an error record is determined, the detected data recorded at the two collection points are compared with the reference data bit by bit. If the detected data are the same as the reference data, this indicates that no IC fault has occurred on the links between the sending node and the collection point, and the comparison result is defined as a “0” event. Otherwise, it can be concluded that IC faults have occurred on the links between the sending node and the collection point, and the comparison result is defined as a “1” event. Accordingly, for each error record, a symptom is generated by combining the comparison results from the two collection points:

$$S_{N_r}=(s_{C_1},s_{C_2}),s_{C_1},s_{C_2}\in \{0,1\}$$

(1)

where $N_r$ is the node address of the error record, with $r\in \{1,2,\cdots ,n\}$, and $s_{C_k}$ is the comparison result from collection point $C_k$, with $k\in \{1,2\}$. Thus, there are four possible symptom modes. For further analysis, suppose that there are $m_r$ possible symptom modes for node $N_r$, which can be represented as follows:

$$\begin{array}{cc}\hfill S_{N_r}^{<1>}& =(s_{C_1}^{<1>},s_{C_2}^{<1>})\hfill \\ \hfill S_{N_r}^{<2>}& =(s_{C_1}^{<2>},s_{C_2}^{<2>})\hfill \\ \hfill ⋮& \hfill \\ \hfill S_{N_r}^{<m_r>}& =(s_{C_1}^{<m_r>},s_{C_2}^{<m_r>})\hfill \end{array}$$

(2)

where $S_{N_r}^{<t>}$ is the t-th symptom mode for node $N_r$, with $t\in \{1,2,\cdots ,m_r\}$, and $s_{C_k}^{<t>}$ is the comparison result from collection point $C_k$ in $S_{N_r}^{<t>}$, with $k\in \{1,2\}$.

Definition 1. 

Communication Link: A communication link $L_{N_r-C_k}$ is the minimum-size set of links through which data are transmitted from node $N_r$ to collection point $C_k$. For example, the communication link $L_{N_1-C_2}$ in the network topology shown in Figure 3 is $\{l_1,l_5,l_6,l_7\}$.

Under different IC fault scenarios, the system will exhibit distinct symptom modes. The details of the symptom modes are introduced as follows:

3.2.1. Symptom Modes for Local IC Faults

As discussed in Section 2.2.1, in scenario A, the detected data recorded at both collection points are different from the reference data; thus, the symptom for node 1 is $S_{N_1}=(1,1)$, which indicates that IC faults have occurred on communication links $L_{N_1-C_1}$ and $L_{N_1-C_2}$. In scenario B, the detected data recorded at both collection points are the same as the reference data; thus, the symptom for node 1 is $S_{N_1}=(0,0)$, which indicates that communication links $L_{N_1-C_1}$ and $L_{N_1-C_2}$ are free of IC faults. Therefore, the symptom modes related to local IC faults correspond to symptoms with the same elements, i.e., $(0,0)$ and $(1,1)$.

3.2.2. Symptom Modes for Trunk IC Faults

As discussed in Section 2.2.2, in scenario C, the detected data recorded at $C_1$ are the same as the reference data, while the detected data recorded at $C_2$ are different from the reference data. Thus, the symptom for node 1 is $S_{N_1}=(0,1)$, which indicates that $L_{N_1-C_1}$ is free of IC faults, while $L_{N_1-C_2}$ has suffered an IC fault. Similarly, if node 3 is transmitting when a trunk IC fault occurs, the symptom for node 3 is $S_{N_3}=(1,0)$. Therefore, the symptom modes related to trunk IC faults correspond to symptoms with mixed elements, i.e., $(0,1)$ and $(1,0)$.

3.3. Derivation of Symptom Domains

Based on the above analysis, each symptom for a node contains information on whether IC faults have occurred on the communication links between that node and each collection point. Hence, in combination with the network topology, each symptom can be used to derive a set of possible faulty links.

Definition 2. 

Symptom Domain: The domain of symptom $S_{N_r}$, which is denoted by $F_{N_r}$, is defined as the set of possible faulty links that can lead to $S_{N_r}$; that is, an IC fault occurring on any link in the corresponding symptom domain can result in $S_{N_r}$.

For the two types of symptom modes, the symptom domains are derived separately, as follows:

3.3.1. Symptom Domains for Local IC Faults

In this case, only the symptoms $(0,0)$ and $(1,1)$ are considered. For symptom $S_{N_r}^{<t>}=(0,0)$, since $s_{C_1}^{<t>}=0$ and $s_{C_2}^{<t>}=0$, then both $L_{N_r-C_1}$ and $L_{N_r-C_2}$ are free of IC faults. In other words, the possible faulty links can be inferred as the drop links other than $L_{N_r-C_1}$ and $L_{N_r-C_2}$. Thus, the domain of symptom $S_{N_r}^{<t>}=(0,0)$ can be derived as

$$F_{N_r}^{<t>}=\left\{l_j\right|l_j\in (L_D-L_{N_r-C_1}\bigcup L_{N_r-C_2})\},\mathrm{s.t.},S_{N_r}^{<t>}=(0,0)$$

(3)

where $L_D$ is the set of all drop links in the network.

For symptom $S_{N_r}^{<t>}=(1,1)$, since $s_{C_1}^{<t>}=1$ and $s_{C_2}^{<t>}=1$, then the IC fault exists on both $L_{N_r-C_1}$ and $L_{N_r-C_2}$ at the same time. That is, the possible faulty links can be inferred as the overlap between $L_{N_r-C_1}$ and $L_{N_r-C_2}$. Thus, the domain of symptom $S_{N_r}^{<t>}=(1,1)$ can be derived as

$$F_{N_r}^{<t>}=\left\{l_j\right|l_j\in L_{N_r-C_1}\bigcap L_{N_r-C_2}\},\mathrm{s.t.},S_{N_r}^{<t>}=(1,1)$$

(4)

3.3.2. Symptom Domains for Trunk IC Faults

In this case, only the symptoms $(0,1)$ and $(1,0)$ are considered. For node $N_r$, if there exists a collection point $C_{v,v\in \{1,2\}}$ such that $s_{C_v}=0$ during the whole data collection process, then $L_{N_r-C_v}$ can be inferred to be fault-free. By conducting the same analysis for all nodes, the set of normal (fault-free) trunk links can be obtained, i.e.,

$$L_{normal}=\bigcup _{r=1}^n\bigcup _{v:s_{C_v}=0}{L}_{N_r-C_v}$$

(5)

In this way, the possible faulty links are first compressed to the trunk links except those in $L_{normal}$, i.e., $L_T-L_{normal}$, where $L_T$ is the set of all trunk links in the network.

For symptom $S_{N_r}^{<t>}=(0,1)$, $s_{C_1}^{<t>}=0$ indicates that $L_{N_r-C_1}$ is fault-free while $s_{C_2}^{<t>}=1$ indicates that $L_{N_r-C_2}$ has an IC fault. That is, the possible faulty links can be inferred as the trunk links that belong to $L_{N_r-C_2}$ and not to $L_{N_r-C_1}$. Thus, in combination with (5), the domain of symptom $S_{N_r}^{<t>}=(0,1)$ can be derived as

$$F_{N_r}^{<t>}=\left\{l_j\right|l_j\in \left(L_T-L_{normal}\right)\bigcap (L_{N_r-C_2}-L_{N_r-C_1})\},\mathrm{s.t.},S_{N_r}^{<t>}=(0,1)$$

(6)

In the same way, it is easy to obtain the following derivation for the domain of symptom $S_{N_r}^{<t>}=(1,0)$:

$$F_{N_r}^{<t>}=\left\{l_j\right|l_j\in \left(L_T-L_{normal}\right)\bigcap (L_{N_r-C_1}-L_{N_r-C_2})\},\mathrm{s.t.},S_{N_r}^{<t>}=(1,0)$$

(7)

Example 1. 

Derivation of the symptom domains: To facilitate the reader’s understanding, the bus topology shown in Figure 3 is used in the following examples. If we assume that an IC fault has occurred on $l_2$, then the symptom for node 2 is $S_{N_2}^{<1>}=(1,1)$, and those for the other nodes are $S_{N_1}^{<1>}=S_{N_3}^{<1>}=S_{N_4}^{<1>}=(0,0)$. The domains of $S_{N_2}^{<1>}=(1,1)$ and $S_{N_1}^{<1>}=(0,0)$ can be derived as follows:

Based on the network topology, we can obtain $L_{N_2-C_1}=\{l_2,l_5\}$ and $L_{N_2-C_2}=\{l_2,l_6,l_7\}$. Since $S_{N_2}^{<1>}=(1,1)$, we can obtain its domain by applying (4).

$$\begin{array}{cc}\hfill F_{N_2}^{<1>}& =L_{N_2-C_1}\bigcap L_{N_2-C_2}\hfill \\ \hfill & =\left\{l_2\right\}\hfill \end{array}$$

Based on the network topology, we can obtain $L_D=\{l_1,l_2,l_3,l_4\}$, $L_{N_1-C_1}=\left\{l_1\right\}$, and $L_{N_1-C_2}=\{l_1,l_5,l_6,l_7\}$. Since $S_{N_1}^{<1>}=(0,0)$, we can obtain its domain by applying (3).

$$\begin{array}{cc}\hfill F_{N_1}^{<1>}& =L_D-L_{N_1-C_1}\bigcup L_{N_1-C_2}\hfill \\ \hfill & =\{l_2,l_3,l_4\}\hfill \end{array}$$

3.4. Fault Symptom Association Model (FSAM)

According to Definition 2 in Section 3.3, each link has a causal relationship with the symptoms whose domains contain that link. That is, if $l_j\in F_{N_u}$, then IC faults occurring on $l_j$ will increase the quantity of observations of symptom $S_{N_u}$. Therefore, for each link, the probability of IC faults occurring on that link can be calculated from the count values of all symptoms causally related to that link.

In this work, FSAMs are used to quantitatively describe the relationship between links and symptoms, including the fault probability for each link and which symptoms a fault on this link can cause. The symptom domains for the two types of IC faults are used to construct separate FSAMs for local and trunk IC faults. In the following subsections, we first introduce the detailed construction process for the local IC fault FSAM and then emphasize the differences in the trunk IC fault FSAM.

3.4.1. FSAM for Local IC Faults (FSAM_Loc)

In this subsection, only the local IC fault-related symptoms $(0,0)$ and $(1,1)$ and their corresponding domains are used to build the FSAM for local IC faults (FSAM_Loc).

Let $S^{loc}$ denote the symptom set formed by sequentially combining the local IC fault-related symptoms of all n nodes:

$$\begin{array}{cc}\hfill S^{loc}=& \{S_{N_1}^{<1>},\cdots ,S_{N_1}^{<m_1^{loc}>},S_{N_2}^{<1>},\cdots ,S_{N_2}^{<m_2^{loc}>},\cdots ,S_{N_n}^{<1>},\cdots ,S_{N_n}^{<m_n^{loc}>}\}\hfill \\ \hfill =& \{S_1,S_2,\cdots ,S_{m_1^{loc}+m_2^{loc}+\cdots +m_n^{loc}}\}\hfill \end{array}$$

(8)

where $m_r^{loc}$ denotes the number of symptom modes related to local IC faults for $N_r$ and $S_i$ denotes the i-th symptom in $S^{loc}$.

Let $F_S^{loc}$ denote the candidate fault location set for $S^{loc}$, i.e., the union of the domains of the symptoms in $S^{loc}$:

$$F_S^{loc}=\bigcup _{r=1}^n\bigcup _{t=1}^{m_r^{loc}}{F}_{N_r}^{<t>}$$

(9)

Based on the count information for each symptom, the actual probability of the occurrence of symptom $S_i$ can be calculated directly from the proportion of the quantity of symptom $S_i$ to the quantity of all symptoms, that is,

$$p\left(S_i\right)={\displaystyle \frac{\mathit{val}\left(S_i\right)}{{\sum }_{S_o\in S^{loc}}\mathit{val}\left(S_o\right)}}$$

(10)

where $\mathit{val}\left(S_i\right)$ denotes the count value for symptom $S_i$.

Using the law of total probability, the probability of the occurrence of $S_i$ ($p\left(S_i\right)$) can also be estimated as follows:

$$\widehat{p}\left(S_i\right)=\sum _{l_j:l_j\in F_S^{loc}}p\left(S_i\right|l_j)·p\left(l_j\right)$$

(11)

where $p\left(l_j\right)$ is the fault probability for link $l_j$ and $p\left(S_i\right|l_j)$ is the probability of detecting $S_i$ when an IC fault occurs on $l_j$.

As elaborated in Section 3.3, the domain of a symptom specifies the fault links that can lead to that symptom. Thus, $p\left(S_i\right|l_j)$ can be calculated based on the domain information of each symptom. If the domain of symptom $S_i$ does not include $l_j$, then when the IC fault occurs on $l_j$, one can not detect $S_i$, hence $p\left(S_i\right|l_j)=0$. Otherwise, $p\left(S_i\right|l_j)$ should be the proportion of the quantity of symptom $S_i$ among the quantity of all symptoms that an IC fault on $l_j$ can lead to, and the symptoms that can be caused by the IC fault on $l_j$ can also be determined by the symptom domains. Hence, $p\left(S_i\right|l_j)$ can be calculated by

$$p\left(S_i\right|l_j)=\left\{\begin{array}{cc}{\displaystyle \frac{\mathit{val}\left(S_i\right)}{{\sum }_{S_o:l_j\in F_{S_o}}\mathit{val}\left(S_o\right)}},\hfill & \mathrm{if}{l}_j\in F_{S_i}\hfill \\ 0,\hfill & \mathrm{if}{l}_j\notin F_{S_i}\hfill \end{array}\right.$$

(12)

Then, based on (10)–(12), the fault probability $p\left(l_j\right)$ can be estimated by minimizing the difference between the actual symptom probability $p\left(S_i\right)$ and the fitted symptom probability $\widehat{p}\left(S_i\right)$, that is,

$$\widehat{p}\left(l_j\right)=\underset{p\left(l_j\right),l_j\in F_S^{loc}}{\mathrm{argmin}}\sum _{S_i\in S^{loc}}{|p\left(S_i\right)-\widehat{p}\left(S_i\right)|}^2$$

(13)

To describe the associations between the symptom set $S^{loc}$ and the candidate fault location set $F_S^{loc}$, FSAM_Loc is built using a matrix bubble diagram, as illustrated in Figure 5. In FSAM_Loc, the Y-axis variable is $S^{loc}$; the X-axis variable is $F_S^{loc}$, the values of which are ordered by the corresponding values of the color variable; the color variable is $\widehat{p}\left(l_j\right)$, which reflects the degree of contribution of IC faults on $l_j$ to $S^{loc}$; and the size variable is $p\left(S_i\right|l_j)$, which reflects whether an IC fault on $l_j$ can lead to $S_i$.

Definition 3. 

Contribution Ranking: The contribution ranking $\mathbb{R}$ is defined as the X-axis vector of the FSAM, which ranks the candidate fault locations in descending order of their fault probabilities. For example, the contribution ranking of the FSAM_Loc shown in Figure 5 is $\mathbb{R}$$=[l_3,l_2,l_4,l_1]$.

In this paper, contribution rankings are used to determine the order in which candidate fault locations are diagnosed in the subsequent diagnosis algorithm.

3.4.2. FSAM for Trunk IC Faults (FSAM_Trk)

In this subsection, only the trunk IC fault-related symptoms $(0,1)$ and $(1,0)$ and their corresponding domains are used to build the FSAM for trunk IC faults (FSAM_Trk).

The symptom set denoted by $S^{trk}$ is formed by sequentially combining the trunk IC fault-related symptoms of all n nodes:

$$\begin{array}{cc}\hfill S^{trk}=& \{S_{N_1}^{<1>},\cdots ,S_{N_1}^{<m_1^{trk}>},S_{N_2}^{<1>},\cdots ,S_{N_2}^{<m_2^{trk}>},\cdots ,S_{N_n}^{<1>},\cdots ,S_{N_n}^{<m_n^{trk}>}\}\hfill \\ \hfill =& \{S_1,S_2,\cdots ,S_{m_1^{trk}+m_2^{trk}+\cdots +m_n^{trk}}\}\hfill \end{array}$$

(14)

where $m_r^{trk}$ denotes the number of symptom modes related to trunk IC faults for $N_r$. Moreover, the candidate fault location set for $S^{trk}$ is

$$F_S^{trk}=\bigcup _{r=1}^n\bigcup _{t=1}^{m_r^{trk}}{F}_{N_r}^{<t>}$$

(15)

Then, the processes of calculating $p\left(S_i\right|l_j)$ and $\widehat{p}\left(l_j\right)$ and constructing FSAM_Trk are the same as those presented in Section 3.4.1; however, note that $l_j\in F_S^{trk}$ and $S_i\in S^{trk}$. Finally, the contribution ranking $\mathbb{R}$ for trunk IC fault diagnosis can be obtained.

Example 2. 

Construction of an FSAM: In this example, the network topology and the fault location assumption are the same as in Example 1.

The symptoms and corresponding count values for all nodes shown in Figure 3 are $S_{N_1}^{<1>}=(0,0)$, with a count of 216; $S_{N_2}^{<1>}=(1,1)$, with a count of 253; $S_{N_3}^{<1>}=(0,0)$, with a count of 233; and $S_{N_4}^{<1>}=(0,0)$, with a count of 626. Accordingly, the symptom set is $S^{loc}=\{S_{N_1}^{<1>},S_{N_2}^{<1>},S_{N_3}^{<1>},S_{N_4}^{<1>}\}=\{S_1,S_2,S_3,S_4\}$.

The symptom domains can be obtained by applying (3) and (4), yielding $F_{N_1}^{<1>}=\{l_2,l_3,l_4\}$, $F_{N_2}^{<1>}=\left\{l_2\right\}$, $F_{N_3}^{<1>}=\{l_1,l_2,l_4\}$, and $F_{N_4}^{<1>}=\{l_1,l_2,l_3\}$. Thus, the candidate fault location set is $F_S^{loc}=\{l_1,l_2,l_3,l_4\}$.

Taking $S_1$ as an example, its actual occurrence probability can be calculated by applying (10), yielding

$$p\left(S_1\right)={\displaystyle \frac{\mathit{val}\left(S_1\right)}{{\sum }_{i\in \{1,2,3,4\}}\mathit{val}\left(S_i\right)}}={\displaystyle \frac{216}{216+253+233+626}}$$

In the same way, we can obtain $p\left(S_2\right)$, $p\left(S_3\right)$, and $p\left(S_4\right)$.

Taking $l_1$ as an example, since $l_1\notin F_{S_1}$, $l_1\notin F_{S_2}$, $l_1\in F_{S_3}$ and $l_1\in F_{S_4}$, the probabilities $p\left(S_i\right|l_1)$ can be calculated by applying (12), as follows:

$$\begin{array}{cc}\hfill p\left(S_1\right|l_1)=& 0\hfill \\ \hfill p\left(S_2\right|l_1)=& 0\hfill \\ \hfill p\left(S_3\right|l_1)=& {\displaystyle \frac{\mathit{val}\left(S_3\right)}{\mathit{val}\left(S_3\right)+\mathit{val}\left(S_4\right)}}={\displaystyle \frac{233}{233+626}}\hfill \\ \hfill p\left(S_4\right|l_1)=& {\displaystyle \frac{\mathit{val}\left(S_4\right)}{\mathit{val}\left(S_3\right)+\mathit{val}\left(S_4\right)}}={\displaystyle \frac{626}{233+626}}\hfill \end{array}$$

In the same way, we can obtain $p\left(S_i\right|l_2)$, $p\left(S_i\right|l_3)$, and $p\left(S_i\right|l_4)$. The results for all probabilities $p\left(S_i\right|l_j)$ in this example are shown in

Table 2. Probabilities $p\left(S_i\right|l_j)$ in Example 2.

$\mathit{p}\left({\mathit{S}}_{\mathit{i}}\right|{\mathit{l}}_{\mathit{j}})$	${\mathit{l}}_1$	${\mathit{l}}_2$	${\mathit{l}}_3$	${\mathit{l}}_4$
$S_1$	0	0.16	0.26	0.48
$S_2$	0	0.19	0	0
$S_3$	0.27	0.18	0	0.52
$S_4$	0.73	0.47	0.74	0

.

Then, we can calculate the fault probabilities for all candidate fault locations using (11) and (13). The results are shown in

Table 3. Fault probabilities for all candidate fault locations in $F_S^{loc}$ in Example 2.

${\mathit{l}}_{\mathit{j}}$	${\mathit{l}}_1$	${\mathit{l}}_2$	${\mathit{l}}_3$	${\mathit{l}}_4$
$\widehat{p}\left(l_j\right)$	$3.33\times {10}^{-15}$	1	$3.49\times {10}^{-15}$	$1.72\times {10}^{-15}$

.

Finally, the FSAM can be built based on the $p\left(S_i\right|l_j)$ in Table 2 and the $\widehat{p}\left(l_j\right)$ in Table 3, as shown in Figure 6.

3.5. Model-Based Maximal Contribution Diagnosis Algorithm (MMCDA)

The process of IC fault diagnosis can be converted into the process of searching for the subset of contribution ranking $\mathbb{R}$ that provides the best explanation for the symptom set $S^{loc}$ (or $S^{trk}$), as shown in Algorithm 1. The best explanation has two properties: (1) the symptoms produced by this subset of faults can cover $S^{loc}$ (or $S^{trk}$), and (2) on the premise that the first condition is satisfied, the number of fault locations in the selected subset is as small as possible.

Algorithm 1 Model-Based Maximal Contribution Diagnosis Algorithm (MMCDA)

Input: symptom set $S^{loc}$ (or $S^{trk}$), contribution ranking $\mathbb{R}$ Output: best-explanation fault set F 1: Initialize the set of symptoms explained by the current link, $S_F=⌀$; the set of symptoms that have already been explained, $S_R=⌀$; the candidate fault location set for $S_R$, $F_R=⌀$; and the best-explanation fault set, $F=⌀$ 2: for $l_j\in \mathbb{R}$do 3:       for $S_i\in S^{loc}\left(S^{trk}\right)$ do 4:            if $p\left(S_i\right|l_j)\ne 0$ then 5:                 $S_F=S_F\cup S_i$ 6:       if $S_R\ne S_R\cup S_F$ then 7:            $S_R=S_R\cup S_F$ 8:            $F_R=F_R\cup \left\{l_j\right\}$ 9:       if $S_R=S^{loc}\left(S^{trk}\right)$ then 10:           $F=F_R$ 11:      else 12:           $S_F=⌀$ 13: return F

Algorithm 1 operates as follows: Initially, the set of symptoms explained by the current link ($S_F$), the set of symptoms that have already been explained ($S_R$), the candidate fault location set for $S_R$ ($F_R$), and the best-explanation fault set (F) are all empty. Then, the algorithm sequentially selects links from the contribution ranking $\mathbb{R}$ and performs the following steps: Step 1: Determine the explainable symptom set $S_F$ of the current link based on the size variable $p\left(S_i\right|l_j)$ in the FSAM. Step 2: Determine whether the explainable symptom set $S_F$ of the current link can increase the size of the explained symptom set $S_R$. If so, include $S_F$ in $S_R$ and add the current link $l_j$ to $F_R$. Step 3: Judge whether the explained symptom set $S_R$ can cover $S^{loc}$ (or $S^{trk}$). If so, keep $F_R$ in F; otherwise, initialize $S_F$ as empty and repeat the above steps until this condition is satisfied. Finally, the elements of the set F are the IC fault locations in the system that collectively provide the best explanation for the symptom set.

Example 3. 

Diagnosis of IC faults using MMCDA: In this example, we perform IC fault diagnosis based on the FSAM shown in Figure 6. From the X-axis of the FSAM, we can obtain the contribution ranking $\mathbb{R}$$=[l_2,l_3,l_1,l_4]$. In accordance with Algorithm 1, link $l_2$ is examined first.

Algorithm step 1: As shown in Figure 6, $p\left(S_1\right|l_2)\ne 0$, $p\left(S_2\right|l_2)\ne 0$, $p\left(S_3\right|l_2)\ne 0$, and $p\left(S_4\right|l_2)\ne 0$; thus, the explainable symptom set corresponding to $l_2$ is $S_F=\{S_1,S_2,S_3,S_4\}$.

Algorithm step 2: The set of symptoms that have already been explained is $S_R=S_F=\{S_1,S_2,S_3,S_4\}$, and the candidate fault location set is $F_R=\left\{l_2\right\}$.

Algorithm step 3: Since $S_R$ can cover the symptom set $S^{loc}$, we can obtain the fault set $F=F_R=\left\{l_2\right\}$, i.e., the IC fault location is $l_2$, which agrees with the initial location assumption in Example 1.

4. Experiments

This section describes the construction of a testbed and reports three case studies conducted to demonstrate the effectiveness of the proposed method. In case study 1, the diagnostic procedure is illustrated in detail using a simple scenario where double trunk IC faults coexist with local IC faults. Then, in case study 2, the complex scenario where three trunk IC faults coexist with local IC faults is studied. Finally, in case study 3, the complex scenario in which four trunk IC faults coexist is investigated.

4.1. Testbed Setup

The schematic layout of the testbed is shown in Figure 7. The testbed is composed of a CAN communication module, an IC fault injection module, and an error collection module. DeviceNet hardware (Rockwell Automation Inc., Milwaukee, WI, USA) is adopted for the communication module, in which the CAN protocol is in both the physical and data link layers. The IC fault injection module includes high-speed analog switches and NI CompactRIO controllers (National Instruments Corp., Austin, TX, USA). The switches are inserted into the cables that need to be injected with IC faults, and each switch is controlled by an independent controller. The occurrences of cable disconnection events follow a Poisson process with an arrival rate of ${\lambda }_{IC}$. The error collection module consists of a CAN transceiver and NI CompactRIO FPGA hardware. When six consecutive dominant bits are detected, the error collection module triggers the collection of bus error records at the two collection points.

The testbed constructed for the case studies is shown in Figure 8. There are eight nodes in the network: node 1, node 2, node 5, node 6, node 10, node 11, node 12, and the PLC. The equivalent topology of the system is shown in Figure 9, where $C_1$ and $C_2$ are the collection points and $N_1$ denotes node 1.

4.2. Case Study 1: Two Local IC Faults and Two Trunk IC Faults

In this case study, as represented by fault locations B, C, D, and F in Figure 9, IC faults occur independently on two different trunk cables and two different local cables, i.e., $l_{11}$, $l_{14}$, $l_3$, and $l_5$. Locations B and D correspond to local IC fault scenarios with fault injection rates of ${\lambda }_{IC}^B=$ 67 faults/s and ${\lambda }_{IC}^D=$ 56 faults/s, respectively. Locations C and F correspond to trunk IC fault scenarios with fault injection rates of ${\lambda }_{IC}^C=$ 50 faults/s and ${\lambda }_{IC}^F=$ 83 faults/s, respectively. For this case study, a total of 12,645 error records were collected, 12,490 of which contained complete address information for symptom generation. The symptom modes for each node and their corresponding count values are shown in

Table 4. Symptoms and corresponding count values for all nodes in case study 1.

Node r	Symptoms for Local IC Fault				Symptoms for Trunk IC Fault
	${\mathit{S}}_{{\mathit{N}}_{\mathit{r}}}^{<\mathbf{1}>}$	$\mathit{val}$	${\mathit{S}}_{{\mathit{N}}_{\mathit{r}}}^{<\mathbf{2}>}$	$\mathit{val}$	${\mathit{S}}_{{\mathit{N}}_{\mathit{r}}}^{<\mathbf{1}>}$	$\mathit{val}$	${\mathit{S}}_{{\mathit{N}}_{\mathit{r}}}^{<\mathbf{2}>}$	$\mathit{val}$
1	$(0,0)$	538	$(1,1)$	3	$(0,1)$	611	$(1,0)$	3
2	$(0,0)$	524	−	−	$(0,1)$	560	$(1,0)$	2
5	$(0,0)$	261	$(1,1)$	350	$(0,1)$	586	−	−
6	$(0,0)$	473	$(1,1)$	2	$(0,1)$	330	$(1,0)$	130
10	$(0,0)$	312	$(1,1)$	331	$(0,1)$	392	$(1,0)$	121
11	$(0,0)$	445	$(1,1)$	2	$(0,1)$	394	$(1,0)$	119
12	$(0,0)$	540	−	−	$(1,0)$	513	−	−
PLC	$(0,0)$	2605	$(1,1)$	4	$(1,0)$	2339	−	−

.

4.2.1. Local IC Fault Diagnosis

In this work, only the symptoms whose ratios to the total number of records for the corresponding node are more than 1% are considered significant for diagnosis. Hence, based on (8) and the symptoms for local IC faults whose ratios are more than 1% in Table 4, the symptom set utilized to diagnose local IC faults is $S^{loc}=\{S_{N_1}^{<1>},S_{N_2}^{<1>},S_{N_5}^{<1>},S_{N_5}^{<2>},S_{N_6}^{<1>},S_{N_{10}}^{<1>},S_{N_{10}}^{<2>},S_{N_{11}}^{<1>},S_{N_{12}}^{<1>},S_{N_{PLC}}^{<1>}\}=\{S_1,S_2,S_3,S_4,S_5,S_6,S_7,S_8,S_9,S_{10}\}$.

Step 1: Derive the domains of all symptoms in $S^{loc}$ via (3) and (4). The results are shown in

Table 5. Domains of the symptoms contained in $S^{loc}$ in case study 1.

Node r	Domains of Symptoms for Local IC Fault
	${\mathit{F}}_{{\mathit{N}}_{\mathit{r}}}^{<\mathbf{1}>}$	${\mathit{F}}_{{\mathit{N}}_{\mathit{r}}}^{<\mathbf{2}>}$
1	$\{l_2,l_3,l_4,l_5,l_6,l_7,l_8\}$	−
2	$\{l_1,l_3,l_4,l_5,l_6,l_7,l_8\}$	−
5	$\{l_1,l_2,l_4,l_5,l_6,l_7,l_8\}$	$\left\{l_3\right\}$
6	$\{l_1,l_2,l_3,l_5,l_6,l_7,l_8\}$	−
10	$\{l_1,l_2,l_3,l_4,l_6,l_7,l_8\}$	$\left\{l_5\right\}$
11	$\{l_1,l_2,l_3,l_4,l_5,l_7,l_8\}$	−
12	$\{l_1,l_2,l_3,l_4,l_5,l_6,l_8\}$	−
PLC	$\{l_1,l_2,l_3,l_4,l_5,l_6,l_7\}$	−

. Then, the candidate fault set $F_S^{loc}=\{l_1,l_2,l_3,l_4,l_5,l_6,l_7,l_8\}$ can be obtained by applying (9).

Step 2: Construct FSAM_Loc based on the local IC fault-related symptom count values in Table 4 and (10)–(13). The results are shown in Figure 10. Accordingly, the contribution ranking is $\mathbb{R}=[l_3,l_5,l_8,l_1,l_2,l_4,l_6,l_7]$.

Step 3: Execute MMCDA based on the FSAM_Loc. As illustrated in Figure 10, the symptoms explained by $\left\{l_3\right\}$ are $\{S_1,S_2,S_4,S_5,S_6,S_8,S_9,S_{10}\}$ and they cannot yet cover $S^{loc}$; additionally, the symptoms explained by $\{l_3,l_5\}$ can cover $S^{loc}$; thus, the local IC fault locations are $l_3$ and $l_5$.

4.2.2. Trunk IC Fault Diagnosis

Based on (14) and the significant symptoms for trunk IC faults in Table 4, the symptom set utilized to diagnose trunk IC faults is $S^{trk}=\{S_{N_1}^{<1>},S_{N_2}^{<1>},S_{N_5}^{<1>},S_{N_6}^{<1>},S_{N_6}^{<2>},S_{N_{10}}^{<1>},S_{N_{10}}^{<2>},$$S_{N_{11}}^{<1>},S_{N_{11}}^{<2>},S_{N_{12}}^{<1>},S_{N_{PLC}}^{<1>}\}=\{S_1,S_2,S_3,S_4,S_5,S_6,S_7,S_8,S_9,S_{10},S_{11}\}$.

Step 1: Derive the domains of all symptoms in $S^{trk}$ via (6) and (7). The results are shown in

Table 6. Domains of the symptoms contained in $S^{trk}$ in case study 1.

Node r	Domains of Symptoms for Trunk IC Fault
	${\mathit{F}}_{{\mathit{N}}_{\mathit{r}}}^{<\mathbf{1}>}$	${\mathit{F}}_{{\mathit{N}}_{\mathit{r}}}^{<\mathbf{2}>}$
1	$\{l_{11},l_{12},l_{13},l_{14}\}$	−
2	$\{l_{11},l_{12},l_{13},l_{14}\}$	−
5	$\{l_{11},l_{12},l_{13},l_{14}\}$	−
6	$\{l_{12},l_{13},l_{14}\}$	$\left\{l_{11}\right\}$
10	$\{l_{13},l_{14}\}$	$\{l_{11},l_{12}\}$
11	$\left\{l_{14}\right\}$	$\{l_{11},l_{12},l_{13}\}$
12	$\{l_{11},l_{12},l_{13},l_{14}\}$	−
PLC	$\{l_{11},l_{12},l_{13},l_{14}\}$	−

. Then, the candidate fault set $F_S^{trk}=\{l_{11},l_{12},l_{13},l_{14}\}$ can be obtained by applying (15).

Step 2: Construct FSAM_Trk based on the trunk IC fault-related symptom count values in Table 4 and (10)–(13). The results are shown in Figure 11. Accordingly, the contribution ranking is $\mathbb{R}$$=[l_{14},l_{11},l_{12},l_{13}]$.

Step 3: Execute MMCDA based on the FSAM_Trk. As illustrated in Figure 11, the symptoms explained by $\left\{l_{14}\right\}$ are $\{S_1,S_2,S_3,S_4,S_6,S_8,S_{10},S_{11}\}$ and they cannot yet cover $S^{trk}$; additionally, the symptoms explained by $\{l_{14},l_{11}\}$ can cover $S^{trk}$; thus, the trunk IC fault locations are $l_{11}$ and $l_{14}$. In summary, the IC fault locations in the network are identified as $l_3$, $l_5$, $l_{11}$, and $l_{14}$, in agreement with the experimental setup.

4.3. Case Study 2: One Local IC Fault and Three Trunk IC Faults

In this case study, as represented by fault locations A, C, D, and F in Figure 9, IC faults occur independently on three different trunk cables and a local cable, i.e., $l_{10}$, $l_{11}$, $l_{14}$, and $l_5$. Location D corresponds to a local IC fault scenario with a fault injection rate of ${\lambda }_{IC}^D=$ 40 faults/s. Locations A, C, and F correspond to trunk IC fault scenarios with fault injection rates of ${\lambda }_{IC}^A=$ 56 faults/s, ${\lambda }_{IC}^C=$ 67 faults/s, and ${\lambda }_{IC}^F=$50 faults/s, respectively. For this case study, a total of 13,266 error records were collected, 13,053 of which contained complete address information for symptom generation. The symptom modes for each node and their corresponding count values are shown in

Table 7. Symptoms and corresponding count values for all nodes in case study 2.

Node r	Symptoms for Local IC Fault				Symptoms for Trunk IC Fault
	${\mathit{S}}_{{\mathit{N}}_{\mathit{r}}}^{<\mathbf{1}>}$	$\mathit{val}$	${\mathit{S}}_{{\mathit{N}}_{\mathit{r}}}^{<\mathbf{2}>}$	$\mathit{val}$	${\mathit{S}}_{{\mathit{N}}_{\mathit{r}}}^{<\mathbf{1}>}$	$\mathit{val}$	${\mathit{S}}_{{\mathit{N}}_{\mathit{r}}}^{<\mathbf{2}>}$	$\mathit{val}$
1	$(0,0)$	294	−	−	$(0,1)$	901	−	−
2	$(0,0)$	275	$(1,1)$	2	$(0,1)$	860	$(1,0)$	2
5	$(0,0)$	280	$(1,1)$	2	$(0,1)$	521	$(1,0)$	333
6	$(0,0)$	226	−	−	$(0,1)$	296	$(1,0)$	510
10	$(0,0)$	3	$(1,1)$	301	$(0,1)$	310	$(1,0)$	506
11	$(0,0)$	205	−	−	$(0,1)$	299	$(1,0)$	515
12	$(0,0)$	251	−	−	$(1,0)$	853	−	−
PLC	$(0,0)$	1284	$(1,1)$	7	$(1,0)$	4017	−	−

.

4.3.1. Local IC Fault Diagnosis

By using the significant symptoms for local IC faults and the corresponding count values in Table 7 and following the same procedure as in Section 4.2.1, the local IC fault location $l_5$ can be determined.

4.3.2. Trunk IC Fault Diagnosis

Based on (14) and the significant symptoms for trunk IC faults in Table 7, the symptom set utilized to diagnose trunk IC faults is $S^{trk}=\{S_{N_1}^{<1>},S_{N_2}^{<1>},S_{N_5}^{<1>},S_{N_5}^{<2>},S_{N_6}^{<1>},S_{N_6}^{<2>},S_{N_{10}}^{<1>},S_{N_{10}}^{<2>},S_{N_{11}}^{<1>},S_{N_{11}}^{<2>},S_{N_{12}}^{<1>},S_{N_{PLC}}^{<1>}\}=\{S_1,S_2,S_3,S_4,S_5,S_6,S_7,S_8,S_9,S_{10},S_{11},S_{12}\}$.

Step 1: Derive the domains of all symptoms in $S^{trk}$ via (6) and (7). The results are shown in

Table 8. Domains of the symptoms contained in $S^{trk}$ in case study 2.

Node r	Domains of Symptoms for Trunk IC Fault
	${\mathit{F}}_{{\mathit{N}}_{\mathit{r}}}^{<\mathbf{1}>}$	${\mathit{F}}_{{\mathit{N}}_{\mathit{r}}}^{<\mathbf{2}>}$
1	$\{l_{10},l_{11},l_{12},l_{13},l_{14}\}$	−
2	$\{l_{10},l_{11},l_{12},l_{13},l_{14}\}$	−
5	$\{l_{11},l_{12},l_{13},l_{14}\}$	$\left\{l_{10}\right\}$
6	$\{l_{12},l_{13},l_{14}\}$	$\{l_{10},l_{11}\}$
10	$\{l_{13},l_{14}\}$	$\{l_{10},l_{11},l_{12}\}$
11	$\left\{l_{14}\right\}$	$\{l_{10},l_{11},l_{12},l_{13}\}$
12	$\{l_{10},l_{11},l_{12},l_{13},l_{14}\}$	−
PLC	$\{l_{10},l_{11},l_{12},l_{13},l_{14}\}$	−

. Then, the candidate fault set $F_S^{trk}=\{l_{10},l_{11},l_{12},l_{13},l_{14}\}$ can be obtained by applying (15).

Step 2: Construct FSAM_Trk based on the trunk IC fault-related symptom count values in Table 7 and (10)–(13). The results are shown in Figure 12. Accordingly, the contribution ranking is $\mathbb{R}=[l_{11},l_{10},l_{14},l_{13},l_{12}]$.

Step 3: Execute MMCDA based on the FSAM_Trk. As illustrated in Figure 12, the symptoms explained by $\{l_{11},l_{10},l_{14}\}$ can cover $S^{trk}$; thus, the trunk IC fault locations are $l_{10}$, $l_{11}$, and $l_{14}$. In summary, the IC fault locations in the network are identified as $l_5$, $l_{10}$, $l_{11}$, and $l_{14}$, in agreement with the experimental setup.

4.4. Case Study 3: Four Trunk IC Faults

In this case study, as represented by fault locations A, C, E, and F in Figure 9, IC faults occur independently on four different trunk cables, i.e., $l_{10}$, $l_{11}$, $l_{13}$, and $l_{14}$, with fault injection rates of ${\lambda }_{IC}^A=$ 56 faults/s, ${\lambda }_{IC}^C=$ 67 faults/s, ${\lambda }_{IC}^E=$ 67 faults/s, and ${\lambda }_{IC}^F=$ 50 faults/s, respectively. For this case study, a total of 14,259 error records were collected, 13,798 of which contained complete address information for symptom generation. The symptom modes for each node and their corresponding count values are shown in

Table 9. Symptoms and corresponding count values for all nodes in case study 3.

Node r	Symptoms for Local IC Fault				Symptoms for Trunk IC Fault
	${\mathit{S}}_{{\mathit{N}}_{\mathit{r}}}^{<\mathbf{1}>}$	$\mathit{val}$	${\mathit{S}}_{{\mathit{N}}_{\mathit{r}}}^{<\mathbf{2}>}$	$\mathit{val}$	${\mathit{S}}_{{\mathit{N}}_{\mathit{r}}}^{<\mathbf{1}>}$	$\mathit{val}$	${\mathit{S}}_{{\mathit{N}}_{\mathit{r}}}^{<\mathbf{2}>}$	$\mathit{val}$
1	$(0,0)$	3	$(1,1)$	1	$(0,1)$	1230	−	−
2	$(0,0)$	2	$(1,1)$	2	$(0,1)$	1172	$(1,0)$	2
5	$(0,0)$	3	$(1,1)$	2	$(0,1)$	869	$(1,0)$	332
6	$(0,0)$	3	−	−	$(0,1)$	587	$(1,0)$	510
10	$(0,0)$	2	$(1,1)$	1	$(0,1)$	651	$(1,0)$	506
11	$(0,0)$	2	−	−	$(0,1)$	298	$(1,0)$	824
12	$(0,0)$	1	$(1,1)$	1	$(1,0)$	1178	−	−
PLC	$(0,0)$	9	$(1,1)$	7	$(1,0)$	5600	−	−

. Since only $(0,1)$ and $(1,0)$ symptoms were significant for diagnosis, it can be concluded that only trunk IC faults exist in the network.

Based on (14) and the significant symptoms for trunk IC faults in Table 9, the symptom set utilized to diagnose trunk IC faults is $S^{trk}=\{S_{N_1}^{<1>},S_{N_2}^{<1>},S_{N_5}^{<1>},S_{N_5}^{<2>},S_{N_6}^{<1>},S_{N_6}^{<2>},S_{N_{10}}^{<1>},S_{N_{10}}^{<2>},S_{N_{11}}^{<1>},S_{N_{11}}^{<2>},S_{N_{12}}^{<1>},S_{N_{PLC}}^{<1>}\}=\{S_1,S_2,S_3,S_4,S_5,S_6,S_7,S_8,S_9,S_{10},S_{11},S_{12}\}$.

Step 1: Derive the domains of all symptoms in $S^{trk}$ via (6) and (7). The results are the same as those shown in Table 8. Then, the candidate fault set $F_S^{trk}=\{l_{10},l_{11},l_{12},l_{13},l_{14}\}$ can be obtained by applying (15).

Step 2: Construct FSAM_Trk based on the symptom count values in Table 9 and (10)–(13). The results are shown in Figure 13. Accordingly, the contribution ranking is $\mathbb{R}=[l_{13},l_{11},l_{10},l_{14},l_{12}]$.

Step 3: Execute MMCDA based on the FSAM_Trk. As illustrated in Figure 13, the symptoms explained by $\{l_{13},l_{11},l_{10},l_{14}\}$ can cover $S^{trk}$; thus, the IC fault locations in the network are $l_{10}$, $l_{11}$, $l_{13}$, and $l_{14}$, in agreement with the experimental setup.

5. Discussion

In this section, the method proposed in this paper is compared to the existing state-of-the-art IC fault diagnosis methods [52,53,54] to show the advantages of the proposed method.

5.1. Diagnostic Accuracy

In the three case studies of Section 4, the trunk IC fault diagnosis results using different methods are summarized in Figure 14 in the form of confusion matrices, and the corresponding diagnostic performance metrics are then obtained and presented in

Table 10. Comparison of trunk IC fault diagnosis performance of different methods.

Method	Case Study 1			Case Study 2			Case Study 3
	FNR	FPR	ACC	FNR	FPR	ACC	FNR	FPR	ACC
[52]	0	0	100%	33%	0	86%	50%	0	71%
[53]	0	0	100%	33%	0	86%	50%	0	71%
[54]	0	0	100%	0	0	100%	0	0	100%
This work	0	0	100%	0	0	100%	0	0	100%

, in which the false-negative rate (FNR), the false-positive rate (FPR), and the accuracy (ACC) are calculated by

$$\begin{array}{cc}\hfill FNR& ={\displaystyle \frac{FN}{TP+FN}}\times 100\%,\hfill \\ \hfill FPR& ={\displaystyle \frac{FP}{FP+TN}}\times 100\%,\hfill \\ \hfill ACC& ={\displaystyle \frac{TP+TN}{TP+TN+FP+FN}}\times 100\%\hfill \end{array}$$

(16)

where $TP$, $TN$, $FP$, and $FN$ are the values of true positives, true negatives, false positives, and false negatives, respectively.

The diagnostic results can be summarized as follows: Firstly, the methods proposed in [52,53] can only make an accurate diagnosis under the condition of double trunk IC faults, while having some extent of missed diagnosis under the condition of multiple trunk IC faults. More specifically, the existing methods can only identify the fault boundaries, e.g., $l_{11},l_{14}$ in case study 1 and $l_{10},l_{14}$ in case studies 2 and 3, while the health status of the links within these boundaries is nondiagnosable. This is because the existing methods use the fault probabilities of links that are roughly estimated only from the symptom distribution to diagnose IC faults, whereas, in essence, the symptom distribution depends on the fault boundaries. (For example, a node will produce the symptom (0, 1) if there is a trunk IC fault to the right of that node; hence, the range of nodes exhibiting the symptom (0, 1) depends only on the location of the rightmost trunk IC fault.) Therefore, even if there is a trunk IC fault within the fault boundaries, this trunk IC fault will be missed and the diagnostic result will still be the fault boundaries since the symptom distribution will not change.

In contrast, both the methods proposed in [54] and in this paper have zero FNR and FPR and 100% ACC under various fault conditions, which indicates that there is no missed diagnosis or misdiagnosis with these two methods. More specifically, these two methods can accurately diagnose the health status of each link in the network, including that within fault boundaries; e.g., these two methods indicate that in the fault boundaries $l_{10}$ and $l_{14}$ of case study 3, $l_{11}$ and $l_{13}$ have IC faults, while $l_{12}$ does not. The reasons for obtaining this accurate result of the two methods are different and are analyzed separately as follows: For the method in [54], this is because this method can gradually find the locations of all IC faults by performing an additional diagnosis for the subnetwork within each fault boundary. (Note that although this method yields accurate diagnostic results, it is less efficient than the proposed method due to the repeated diagnostic process; see the next subsection for relevant comparison and discussion.) For the method in this work, this is because the proposed method takes into account that the occurrence of a trunk IC fault within the fault boundary will cause a change in the number of symptoms observed; in this way, all trunk links with IC faults can be distinguished from normal links based on the exact fault probability for each link calculated from the symptom count values. Therefore, it can be concluded that the diagnostic accuracy of the proposed method has an improvement over that of most existing methods and is the highest among the existing methods.

In addition, the impact of the number of error records on the diagnostic accuracy of the proposed method is analyzed. For the different fault conditions in the three case studies, we apply the proposed method for diagnosis under six different data sizes, respectively. Under each data condition, we conduct 300 groups of repeated experiments to obtain the means and standard deviations of the diagnostic performance metrics. Figure 15 shows the trends of several diagnostic performance metrics versus data size. As seen in the figure, under different fault conditions, (1) as the data size grows, both FNRs and FPRs decrease and the ACCs increase; (2) when the data size is below the order of magnitude of ${10}^3$, the ACCs vary in wide ranges and their means have not uniformly reached 95.0%, and the FPRs and FNRs are relatively large (>3.0%), which implies that there are considerable degrees of misdiagnosis and missed diagnosis; (3) when the data size is above the order of magnitude of ${10}^3$, as the data size increases, the ACCs can uniformly stabilize above 99.0% and the FPRs and FNRs uniformly stabilize below 3.0%. Therefore, it can be concluded that, as a rule of thumb, 1000 error records are generally sufficient for an accurate diagnosis by the proposed method.

5.2. Diagnostic Efficiency

In this paper, we use the number of diagnostic rounds required to accurately localize all trunk IC faults to evaluate the efficiency of a diagnosis method, where a diagnostic round consists of installing sensors, processing data, and executing algorithms. The higher the number of diagnostic rounds, the lower the diagnostic efficiency. The numbers of diagnostic rounds for different methods in three case studies are shown in

Table 11. Comparison of diagnostic rounds of different methods.

Method	Diagnostic Round
	Case Study 1	Case Study 2	Case Study 3
[52]	1	−	−
[53]	1	−	−
[54]	2	2	3
This work	1	1	1

and the relevant details are analyzed as follows:

Both [52,53] perform only one round of diagnosis on the network. As discussed in Section 5.1, [52,53] are only able to make an accurate diagnosis of the dual trunk fault scenario, such as case study 1, and hence the number of diagnostic rounds for [52,53] in case study 1 is 1. Whereas in case studies 2 and 3, [52,53] cannot diagnose the fault locations correctly at all, hence the numbers of diagnostic rounds are not considered. In [54], its divide-and-conquer diagnosis process is repetitive. It first diagnoses the whole network to determine the fault boundaries, then diagnoses the subnetwork within the fault boundaries individually to determine new fault boundaries, and so on until there is no fault boundary.

For example, in case study 3, [54] locates the faults on $l_{10}$ and $l_{14}$ in the first diagnostic round, and determines that the fault boundaries are $l_{10}$ and $l_{14}$; the second round is then performed on the subnetwork between $l_{10}$ and $l_{14}$, which locates the faults on $l_{11}$ and $l_{13}$ and determines that the new fault boundaries are $l_{11}$ and $l_{13}$; the third round is then performed on the subnetwork between $l_{11}$ and $l_{13}$, from which it is determined that the links within this subnetwork are fault-free; thus, the number of diagnostic rounds for [54] is 3 in case study 3.

In contrast, the method proposed in this work determines the IC fault locations based on the exact fault probability of each link, which allows the proposed method to locate all trunk IC fault locations with only one diagnostic round. Therefore, the number of diagnostic rounds for the proposed method is 1 in all three case studies. As shown in Table 11, the proposed method requires fewer rounds to make an accurate diagnosis than existing methods, which indicates that the diagnostic efficiency of the proposed method has an improvement over that of the existing methods.

In addition, note that the proposed method only needs to attach the sensor to the end of the network, a position commonly using open ports to facilitate hookup of external devices, whereas [54] requires reconfiguring the sensor layout and repeatedly hooking up and removing the sensors inside the network when diagnosing the subnetworks within the fault boundaries.

However, the interior of some CAN-based industrial networks (e.g., DeviceNet) is often not directly accessible. The method proposed in this work is, therefore, more practical to implement in industrial environments than existing methods.

In summary, compared with [52,53], the proposed method has shown clear improvements in both diagnostic accuracy and efficiency; compared with [54], the proposed method has shown higher diagnostic efficiency while guaranteeing the same 100% diagnostic accuracy. Therefore, it can be concluded that the comprehensive diagnostic capability of the proposed method is superior to that of the existing methods.

6. Conclusions

In this paper, a fault symptom association model-based IC fault diagnosis method for CANs using symptom count information is developed. The symptoms observed in various IC location scenarios and their domains are derived. Fault symptom association models are built to quantitatively describe the dependence between symptoms and fault locations, based on which a model-based maximal contribution diagnosis algorithm is developed to locate the IC faults in the network. The experimental results of case studies conducted to demonstrate the effectiveness of the proposed method show that the IC fault locations determined via the proposed method agree well with the imposed experimental conditions in various scenarios, including double IC faults on both drop and trunk cables, multiple IC faults on trunk cables, and multiple IC faults on both drop and trunk cables. Further discussion shows that the comprehensive diagnostic capability of the proposed method is superior to that of the existing IC fault diagnosis methods, as evidenced by the fact that the proposed method achieves more accurate diagnosis with higher efficiency.

Considering that the proposed method and existing works are constrained to open-circuit faults, bus topology networks, and limited-variation data frames, future work will include (1) extending the current method to other common wiring fault scenarios, such as short-circuit IC faults and hybrid faults with coexisting open-circuit IC faults and short-circuit IC faults, (2) improving the current method to enable its application to several complex topologies, such as tree topologies and star topologies, and (3) developing the particular data treatment procedure for real-time data frames, such as sensor/actuator-related binary/text data frames.