Methods and systems for monitoring a controller area network (CAN) bus

Abstract

A method (200) for monitoring a Controller Area Network (CAN) bus (12), comprising: Receiving (210) error data (38, 42) in connection with the CAN bus (12); processing (230) the error data (38, 42) by a processor (16a) with at least one software-based method to determine a first suggestion set (40); Processing (220) the error data (38, 42) by a processor (16a) with at least one hardware-based method to determine a second suggestion set (44); Processing the first proposal set (40) and the second proposal set (44) by a processor (16a) to determine a decision (46); and Generating (330) a diagnosis of the CAN bus (12) by a processor (16a) based on the decision (46), Iterating the processing (220) of the error data (38, 42) with at least one software-based method, the processing (220) of the error data (38, 42) with at least one hardware-based method and the processing of the first suggestion set (40) and second suggestion set (44) for a number N before the diagnosis is created, where if a certain decision is equal to the previously determined decision, a counter is incremented (310) and evaluated (320), and wherein if the counter does not reach a threshold value, error data (38, 42) are loaded (210) and new suggestion sets (40, 44) are calculated.

Description

[0001] The technical field concerns Controller Area Networks in general and, in particular, the methods and systems for diagnosing a Controller Area Network.

[0002] Vehicles typically contain a number of controllers communicatively linked via a bus. A Controller Area Network (CAN) bus is a vehicle bus over which controllers and other devices can communicate with each other without a host computer. Communication between controllers on the CAN bus occurs according to a message-based protocol originally designed for multiplexed electrical wiring in vehicles, but also finds use in many other vehicular and non-vehicular applications.

[0003] US 2015 / 0 082 096 A1 discloses a CAN network comprising a plurality of CAN elements with a communication bus and a plurality of controllers. A method for monitoring the CAN comprises detecting the occurrence of a first short-lived fault and a second short-lived fault within a predefined time window. A first fault set comprising at least one inactive control unit associated with the first short-lived fault and a second fault set comprising at least one inactive control unit associated with the second short-lived fault are identified. Based on the first and second fault sets, an intermittent fault is localized in the CAN.

[0004] US 2010 / 0 161 307 A1 discloses a test environment for testing the functionality of software, comprising an input model, a hardware model, and a resource modeler. The input model represents an input system used in conjunction with the software. The hardware model represents one or more hardware components used in conjunction with the software. The resource modeler is coupled to the input model and the hardware model and configured to estimate the effects of states of the hardware components, the input system, or both on the software.

[0005] CN 1 03 487 276 A discloses a platform for condition monitoring and fault diagnosis based on a CAN bus, consisting of the CAN bus and a relay. The CAN bus is divided into different network segments by the relay, so that a control unit of each subsystem belongs to the same network segment. The platform further comprises a monitoring and diagnostic device connected to a network segment of the CAN bus. The monitoring and diagnostic data of the monitoring and diagnostic device are obtained from a bus data platform of an original system, and the status signal flows of each subsystem, which are generated when a transmitting platform is operating, are continuously obtained to form time-related data of an operating state of the transmitting platform.According to the universal condition monitoring and fault diagnosis platform, the temporal relative data and a fault diagnosis model are combined, and characteristic parameters are extracted from the data streams and input into a knowledge base, which serves as the information basis for fault diagnosis. The fault diagnosis model corresponds to the characteristic parameters of each subsystem and is independent of the transmitting platform.

[0006] US 7 812 617 B2 discloses a system and method for detecting a fault in a faulty network element of a bus network having two or more transmitters. The method comprises transmitting a signal with predetermined parameters from one of the transmitters to the bus network; receiving the signal; and determining whether the first signal is followed by a tail, which is an echo indicative of a faulty network element. The location of the faulty network element can be determined by transmitting a second signal with predetermined parameters from a second transmitter to the bus network; receiving the second signal; and determining whether the second signal is followed by a second tail, which is an echo indicative of the faulty network element; and if tails are detected, the location of the faulty network element is determined by an algorithm executor through triangulation.

[0007] CN 1 03 293 008 A discloses a vehicle diagnostic device comprising a memory and a memory module. The memory is configured to store a Chinese character library, a vehicle model parameter database, and a CAN message controller. The CAN controller transceiver is connected to the vehicle and is used to receive a CAN message from the vehicle. The processor is configured to generate and update the vehicle model parameter database and execute the vehicle model parameter database. It generates and updates the model parameter database, creates a monitored message list, and manages this list according to the configured vehicle model parameters. Furthermore, it monitors a plurality of CAN messages from the vehicle according to the messages in the monitored message list and performs fault diagnosis on the vehicle based on the monitoring result.

[0008] It is desirable to monitor the CAN bus for errors. Some monitoring systems monitor physical layer signals of the CAN bus, e.g., using hardware (voltage measurement circuit) to measure voltage for errors. Other monitoring systems monitor CAN messages, i.e., a software-based approach to troubleshooting.

[0009] Accordingly, it is desirable to provide methods and systems for monitoring CAN bus usage through a consolidated approach. Furthermore, other desirable functions and features of the present invention will become apparent from the following detailed description and appended claims, taken in conjunction with the accompanying drawings, as well as the foregoing technical field and background.

[0010] A method and system for monitoring a Controller Area Network (CAN) bus are provided. In one embodiment, a method includes: receiving fault data associated with the CAN bus; processing the fault data, by a processor using software-based techniques, to determine a first suggestion set; processing the fault data, by a processor using hardware-based techniques to determine a second suggestion set; processing the first and second suggestion sets, by the processor, to determine a fault decision; and generating, by the processor, a diagnostic of the CAN bus based on the fault decision.

[0011] In one embodiment, a system includes a non-transitory computer-readable medium. The non-transitory computer-readable medium includes a software-based resolution module that receives errors associated with the CAN bus and that processes the error data, via a processor, with a software-based method to determine a first suggestion set. The non-transitory computer-readable medium further includes a hardware-based resolution module that, via the processor, processes the error data with a hardware-based method to determine a second suggestion set. The non-transitory computer-readable medium further includes an evaluation module that, via a processor, processes the first and second suggestion sets to determine a fault decision. The non-transitory computer-readable medium further includes a diagnostic module that, via the processor, generates a diagnosis of the CAN bus based on the fault decision.

[0012] In one embodiment, a vehicle includes a plurality of controllers communicatively coupled via a Controller Area Network bus, wherein at least one of the controllers includes a non-transitory computer-readable medium. The non-transitory computer-readable medium includes a software-based resolution module that receives faults associated with the CAN bus and that processes the fault data via a processor with a software-based method to determine a first suggestion set. The non-transitory computer-readable medium further includes a hardware-based resolution module that, via the processor, processes the fault data with a hardware-based method to determine a second suggestion set. The non-transitory computer-readable medium further includes an evaluation module that processes the first and second suggestion sets via a processor to determine a fault decision.The non-transitory computer-readable medium further includes a diagnostic module that generates, via the processor, a diagnosis of the CAN bus based on the error decision.

[0013] The present disclosure will now be described in conjunction with the following drawing figures, wherein like reference numerals designate like elements and wherein: Fig. 1 is a block diagram illustrating a vehicle having a CAN bus and a monitoring system in accordance with various embodiments; Fig. 2 is a data flow diagram illustrating the monitoring system in accordance with various exemplary embodiments; and Fig. 3 is a flowchart illustrating a method that may be performed by the monitoring system according to exemplary embodiments.

[0014] As mentioned with reference to Fig. 1, a monitoring system, generally depicted at 100, is associated with a vehicle 10 according to various embodiments. Generally, the monitoring system 100 monitors a Controller Area Network (CAN) bus 12 of the vehicle 10 for faults. In various embodiments, the monitoring system monitors the CAN bus 12 using a hardware-based approach and a software-based approach to monitor fault data; further, it performs an analysis of the fault data and generates a fault probability. The fault probability is then used to diagnose the CAN bus.

[0015] As in Fig. 1, the vehicle 10 generally includes a plurality of controllers 14a-14n that communicate via the CAN bus 12. Each of the controllers 14a-14n includes at least one processor 16a-16n and a computer-readable storage device 18a-18n. The processors 16a-16n may be a custom-made or off-the-shelf processor, a central processing unit (CPU), a graphics processing unit (GPU), an auxiliary processor among a plurality of processors coupled to the controller 14a-14n, a semiconductor-based microprocessor (in the form of a microchip or chipset), a macroprocessor, a combination thereof, or generally any device for executing instructions. The computer-readable storage device or media 18a-18n may include volatile and non-volatile memory in a read-only memory (ROM), a random-access memory (RAM), and a keep-alive memory (KAM).KAM is persistent or non-volatile memory that can be used to store various operating variables while the processor 44 is powered off. The computer-readable storage device or media 18a-18n can be implemented using any of a number of known storage devices, such as PROMs (programmable read-only memory), EPROMs (electrical PROMs), EEPROMs (electrically erasable PROMs), flash memory, or any other electrical, magnetic, optical, or combination storage devices capable of storing data, some of which represent executable instructions used by the controller 14a-14n in controlling the vehicle 10.

[0016] The instructions may include one or more separate programs, each comprising an ordered collection of executable instructions for implementing logical functions. The instructions, when executed by processor 16a-16n, receive and process signals from sensors (not shown), perform logic, calculations, methods, and / or algorithms to control other components of vehicle 10, and generate control signals to control the components of vehicle 10 based on the logic, calculations, methods, and / or algorithms.

[0017] In various embodiments, one or more instructions 102 from at least one of the controllers 14a are part of the monitoring system 100 and, when executed via the processor 16a, monitor the CAN bus 12 for errors (e.g., link errors, controller errors, bus shorts or impedance errors, CAN-H ground error, CAN-L ground error, CAN-L open, CAN-H open, etc.), generate a decision and a probability of the decision based on the monitoring, and diagnose the CAN bus 12 based on the decision and the probability. In various embodiments, when executed via the processor 16a, one or more of the instructions set a diagnostic code associated with the CAN bus 12 and / or generate a notification signal based on the monitoring.

[0018] With reference to Fig. 2 illustrates a functional block diagram of the instructions 102 of the monitoring system 100 grouped by modules in detail. Understandably, various embodiments of the monitoring system 100 within the meaning of the present disclosure may include any number of sub-modules. Understandably, the Fig. 2 can be combined and / or further subdivided to similarly monitor the air filter CAN bus 12. In various embodiments, the monitoring system 102 includes a software-based solution module 30, a hardware-based solution module 32, a suggestion evaluation module 34, and a diagnostic module 36.

[0019] The software-based solution module 30 receives data 38 indicating errors on the CAN bus 12. The data 38 includes CAN messages sent by each controller 14a-14n on the CAN bus 12. For example, a message consists of 44 or more bits with a value of either 1 or 0. There is an identification field in the CAN message that indicates the message ID. Based on the vehicle signal dictionary, the message ID can be associated with the sender controller name and confirmed by the software-based solution module 30. Based on the received data 38, the software-based solution module 30 identifies an error and generates a suggestion set 40 based on the software analysis methods.

[0020] For example, if a message from a controller 14b is received regularly, this indicates that this controller 14b and the link between the controller 14b and the monitoring controller 14a are in good condition. On the other hand, if a certain number of expected messages are missing, this indicates that one or more errors may be occurring in the transmitter controller 14b or on the CAN bus 12. Therefore, by monitoring these messages, the software-based solution module 30 can determine the activity of each controller 14a-14n and further make the diagnostic decision.

[0021] In various embodiments, the proposal set 40 is referred to as f i,j where i represents the error type index (i = 1, 2, ... M) and j represents the location index (j = 1, 2, ... N) and a power set (Θ) is defined as the set of each signal error and its combination (including all connections and uncertainty): Θ={{f1,1},...,{fM,N},{f1,1,f1,2},...,{f1,1,f1,2,...fM,N}}.

[0022] Similarly, the software-based solution module 32 receives data 42 indicating errors on the CAN bus 12. The data 42 includes some physical (electrical) measurements for the CAN bus, e.g., CAN H voltage, CAN L voltage, bus current, bus resistance, or bus capacitance. Based on the data 42, the hardware-based solution module 32 identifies an error and generates a suggestion set 44 based on the hardware analysis methods.

[0023] For example, the pattern of physical measurements can be evaluated for indications of other fault causes. For example, if a short-circuit fault occurs between CAN-H and CAN-L, the voltage between CAN-H and CAN-L will be cut off and correspond to approximately 2.5 V, and the bus resistance will be very low. Likewise, other faults, such as CAN-H ground short, CAN-L ground short, CAN-H short, CAN-L short, CAN-L open, CAN-H open, reversed wire connections, or loss of the terminator, have unique fault signatures related to the bus voltage or other physical measurements and can be evaluated. Therefore, by monitoring these physical measurements, the hardware-based solution module 33 can identify a pattern and make the diagnostic decision based on it.

[0024] In various embodiments, the proposal sentence 44 is referred to as J i,jwhere i represents the error type index (i = 1, 2, ... M) and j represents the location index (j = 1, 2, ... N) and a power set (Θ) is defined as the set of each signal error and its combination (including all connections and uncertainty): Θ={{f1,1},...,{fM,N},{f1,1,f1,2},...,{f1,1,f1,2,...fM,N}}.

[0025] The proposal evaluation module 34 generates a decision 46 and a probability 48 associated with the decision based on the proposal set 40 of the software-based solution module 30 and the proposal set 44 from the hardware-based solution module 32. As described below with respect to Fig. As explained in detail in Figure 3, the proposal evaluation module 34 generates the decision 46 and the probability 48 based on the Dempster-Shafer evidence theory, the decision tree approach, a knowledge base, and / or other derivations. The Dempster-Shafer theory is a computational approach for integrating different information sources by considering the probability and confidence level of each source. The knowledge base is a heuristic approach for generating integrated decisions from different information sources using predefined rules.

[0026] The diagnostic module 36 diagnoses the CAN bus 12 based on the decision 46 and the probability 48 and generates signals based thereon, notification signals and / or messages 50.

[0027] Now with reference to Fig. 3 and continue on Fig. 1 and Fig. 2, a flowchart illustrates a monitoring method 200 that can be used by the monitoring system 100 in the context of the various embodiments. As can be seen from the disclosure, the sequence of operations within the methods is not limited to sequential processing, as in Fig. 3, but can occur in any suitable order according to the present disclosure. The method 200 can be varied, e.g., by simplifying the method 200 or by using the decision tree approach if the probability is not desired. This is because the decision tree approach is a special case of the Dempster-Shafer theory approach.

[0028] In an example, the method might start at 205. The error data 38, 42 is loaded at 210. The suggestion set 44 from the hardware-based solution module 32 is determined based on the error data 42 at 220; and a suggestion set 40 from the software-based solution module 30 is determined based on the error data 38 at 230.

[0029] It is determined whether results are available for both hardware and software at 240. For example, in some instances, the hardware-based or software-based solution may not provide a result if data 38 or data 42 are insufficient to make a decision. If results for both solutions are not available at 240, the process continues by loading additional data at 210.

[0030] However, if results are available for at least one of the solutions at 240, the procedure continues by calculating a probability mass of the two proposal sets 40, 44 and generating a decision according to the Dempster-Shafer theory at 250-270.

[0031] In particular, at 250, the probability mass contributed to the decision by proposal set 44 of the hardware-based solution is defined as m H (f H ), for example, using the following relationship: mH(fH)=f(NH, SH), mH(Θ)=1−mH(fH), and the probability mass contributed to the decision by proposal set 40 of the software-based solution as ms(f H ), for example, using the following relationship: mS(fS)=g(Wi,Mi),mS(Θ)=1−mS(fS).

[0032] Where NH represents the number of samples used in a hardware-based solution. SH represents the sampling rate used in the hardware-based solution. W i represents a length of a monitoring window of ECU i. M i represents a message selected for monitoring the status of ECU i. The probability mass functions (1) and (2) may deviate from the given form as long as they represent the probability or confidence level of hardware-based or software-based solutions, respectively.

[0033] At 260, the probability mass of the error candidate m (f c ) based on the probability mass obtained from the proposal set of the hardware-based solution m H (f H ) (replaces m1[f1]) and on the probability mass obtained from the proposed set of the hardware-based solution m S (f S) (replaces m2[f2]) and using the following relationships: mc(fc)=m1(f1)⊕m2(f2)=k∑f1∩f2=fcm1(f1)m2(f2), wherek−1=1−∑f1∩f2=∅m1(f1)m2(f2).

[0034] At 270, the decision of the final error set f I calculated as follows: fI={ fH∩fS,if fH∩fS≠Φargmaxfcmc(fc), where fc∈{fH,fS,Θ}Otherwise mI(fI)=max(mc(fc))

[0035] However, if f Iis set to zero and the knowledge library is available at 280, the final decision is recalculated using domain knowledge at 290. For example, if the decision from the software-based approach is that the ECU is normal or the network is normal, and the decision from the hardware-based approach is any fault, the integration output will be the fault reported by the hardware-based approach. This scenario may be caused by intermittent faults, or the fault may not affect bus communication.

[0036] In another example, if the software-based approach's decision is an unknown fault and the hardware-based approach's decision is an ECU ground fault, the integration output is the ECU ground fault. This scenario can be caused by a common ground fault. In this situation, the list of inactive ECUs is retained for further manual diagnostics.

[0037] In yet another example, if the software-based approach determines an unknown fault and the hardware-based approach determines a normal bus voltage, both open and network, the integration output is the ECU or power supply fault. This scenario can be caused by a common power supply fault or an ECU "bubbling idiot" fault (abnormally continuously sending messages). In this situation, the list of inactive ECUs is retained for further manual diagnosis.

[0038] Thereafter, if the decision is not equal to the previously determined decision at 300, the method continues at 210 with the loading of additional data 38, 42 and with the calculation of new proposal sets 40, 44. However, if the determined decision 46 is equal to the previously determined decision at 300, a counter C is incremented at 310 and evaluated at 320. If the counter C does not reach a threshold T1 (e.g., 3, 4, 5, or another number), or, in other words, if the decision 46 was not equal for a threshold number of iterations, the method continues with the loading of data at 210 and with the calculation of new proposal sets 40, 44.

[0039] Once the counter reaches the threshold at 320, a decision can be made. The error set and the determined probability are stored, and the CAN bus is diagnosed based on the data stored at 330. The procedure can then be terminated at 340.

[0040] In various embodiments, the proposal sets 40, 44 of the hardware-based solution module 32 and those of the software-based solution module 30 may be compatible. For example, one may assume that a hardware error, such as the CAN-H error, is open on Link 1 (between a first and a second controller as f 7,1 The 7th knowledge source in the hardware-based solution module 32 is considered as the output. Thus, the proposal sentence 44 from the hardware-based solution module 32 {(f 7,1 ∪ f 7,2 ... ∪f 7,13 )}and the proposal set 40 from the software-based solution module 30 is {(f 6,1 ∪ f 7,1 ∪ f 10,1∪ f 9,14 ∪ f 10,14 )}. Exemplary probability masses for network state identification contributed by the hardware-based solution module 32 and the software-based solution module 30 are calculated by the pre-trial evaluation module 34 as follows: mh=[mh(f7,1∪f7,2...∪ f7,13)=0.92 mh(Θ)=0.08] and ms=[ms(f6,1 ∪ f7,1 ∪ f10,1 ∪ f9,14 ∪ f10,14)ms(Θ)=0.02]. Table 1 m s (f s ) = 0,98 m s (Θ) = 0.02 m h (f h )= 0,92 m(f h ∩ f s )=m(f 7,1 )= m(f h ∩ Θ)= m(f h )= 0,9016 0,0184 m h (Θ) = 0.08 m(Θ ∩ f s )=m(f s )= m(Θ)= 0,0016 0,0784

[0041] Where f h ∩ f s represents the proposal resulting from the intersection point (f 7,1 ∪ f 7,2 ... ∪ f 7,13 ) from the hardware-based solution module and (f 6,1 ∪ f 7,1 ∪ f 10,1 ∪ f 9,14 ∪ f 10,14 ) is formed from the software-based solution module. f h ∩ Θ represents the proposal resulting from the intersection of the (f 7,1 U f 7,2 ... ∪ f 7,13) hardware-based solution module and the uncertainty (Θ) from the software-based solution module. Θ represents the intersection of the uncertain proposals from the hardware-based solution module and the software-based solution module. The uncertainty (Θ) from the software-based solution module is h (f 7,1 ) has the highest probability mass. Thus, the proposal evaluation module selects 34 m h (f 7,1 ) as output, which represents the fusion of the proof of the hardware-based solution module 32 and the software-based solution module 30 and the final decision 46, as well as the probability 48.

[0042] In various embodiments, the proposal sets 44, 40 of the hardware-based solution module 32 and those of the software-based solution module 30 may be incompatible. For example, one may assume that a potential-free error of the control unit ECU (RDCM) occurred, which is indicated as f 9,20The voltage offset that occurs due to this error is not significant, and the error itself may not be detected by the hardware-based solution module 32. Therefore, the 24th knowledge source is considered as an output in the hardware-based solution module 32. Thus, the proposal set 44 is from the hardware-based solution module ((f 13,1 ∪ f 13,2, ... ∪ f 13,13 ∪ f 11 ∪ f 12 )}, and the proposal set 40 from the software-based solution module 30 is (f 9,20}. The probability masses for network state identification contributed by the hardware-based solution module 32 and the software-based solution module 30 are calculated by the pre-evaluation module 34 as follows: mh=[mh(f13,1 ∪ f13,2... ∪ f13,13 ∪ f11 ∪ f12)=0.9ms(Θ)=0.1]. and ms=[ ms(f9,20)=0.98ms(Q)=0.02]. Table 2 m s (f s ) = 0,98 m s (Θ) = 0.02 m h (f h )= 0,90 m(f h ∩ f s ) = m(Ø) = 0,882 m(f h ∩ Θ) = m(f h ) = 0,018 m h (Θ) = 0.10 m(Θ ∩ f s ) = m(f s ) = 0,098 m(Θ) = 0,002 k−1=1−0.882=0.118,k=8.475 Table 3 m s (f s ) = 0,98 m s (Θ) = 0.02 m h (f h )= 0,90 m(f h ∩ f s )=m(Θ)= 0 m(f h ∩ Θ)= m(f h )= 0,1525 m h (Θ) = 0.10 m(Θ ∩ f s )=m(f s )=0,83055 m(Θ)= 0,01695

[0043] The one by m s (f 9,20 ) has the highest probability mass. Thus, the proposal evaluation module selects 34 m s (f 9,20 ) as output, which represents the fusion of the proof of the hardware-based solution module 32 and the software-based solution module 30 and the final decision 46, as well as the probability 48.

Claims

[1] A method (200) for monitoring a Controller Area Network (CAN) bus (12), comprising: Receiving (210) error data (38, 42) in connection with the CAN bus (12); processing (230) the error data (38, 42) by a processor (16a) with at least one software-based method to determine a first suggestion set (40); Processing (220) the error data (38, 42) by a processor (16a) with at least one hardware-based method to determine a second suggestion set (44); Processing the first proposal set (40) and the second proposal set (44) by a processor (16a) to determine a decision (46); and Generating (330) a diagnosis of the CAN bus (12) by a processor (16a) based on the decision (46), Iterating the processing (220) of the error data (38, 42) with at least one software-based method, the processing (220) of the error data (38, 42) with at least one hardware-based method and the processing of the first suggestion set (40) and second suggestion set (44) for a number N before the diagnosis is created, where if a certain decision is equal to the previously determined decision, a counter is incremented (310) and evaluated (320), and wherein if the counter does not reach a threshold value, error data (38, 42) are loaded (210) and new suggestion sets (40, 44) are calculated. [2] The method (200) of claim 1, further comprising processing (250), by the processor (16a), the first and second proposal sets (40, 44) to determine a probability mass, and wherein generating the diagnosis is based on the probability mass. [3] The method (200) of claim 2, wherein the decision is based on a highest probability mass. [4] The method (200) of claim 1, wherein processing the first and second proposal sets (40, 44) is based on Dempster-Shafer theory. [5] The method (200) of claim 1, wherein processing the first and second proposal sets (40, 44) is based on a decision tree approach. [6] The method (200) of claim 1, wherein processing the first suggestion set (40) and second suggestion set (44) is based on a knowledge database. [7] The method (200) of claim 1, wherein the software-based method evaluates messages on the CAN bus (12). [8] The method (200) of claim 1, wherein the hardware-based method evaluates the physical measurements of the CAN bus (12). [9] System (100) for monitoring a Controller Area Network (CAN) bus (12), comprising: a non-transitory computer-readable medium comprising: a software-based solution module (30) that receives errors associated with the CAN bus (12) and that processes the error data (38, 42) via a processor (16a) with a software-based method (230) to determine a first suggestion set (40); a hardware-based solution module (32) that processes the error data (38, 42) via the processor (16a) using a hardware-based method (230) to determine a second suggestion set (44); an evaluation module (34) which processes the first proposal set (40) and second proposal set (44) via a processor (16a) to determine a decision (46); and a diagnostic module (36) which generates a diagnosis of the CAN bus (12) via the processor (16a) based on the decision (46), wherein the processing of the error data (38, 42) with at least one software-based method, the processing of the error data (38, 42) with at least one hardware-based method and the processing of the first suggestion set (40) and second suggestion set (44) are iterated for a number N before the diagnosis is created, where if a particular decision is equal to the previously determined decision, a counter is incremented and evaluated, and wherein if the counter does not reach a threshold value, error data (38, 42) are loaded (210) and new suggestion sets (40, 44) are calculated.

Images