DE102014112102B4 - Method for monitoring a controller area network for fault detection - Google Patents

Abstract

A method of monitoring a controller area network (CAN) comprising multiple CAN elements comprising a communication bus and multiple controllers, the method comprising: occurrences of a first short CAN fault and a second short CAN fault within a predefined time window are detected; a first set of errors is identified which comprises at least one inactive controller that is associated with the first brief CAN error; characterized in thata second set of errors is identified which comprises at least one inactive controller associated with the second brief CAN error; and locating an intermittent fault in the CAN based on the first and second sets of faults; wherein detecting occurrences of the first short CAN fault and the second short CAN fault within the predefined time window comprises: the first short CAN error is detected; andthe second short duration CAN fault occurring after the detection of the first short duration CAN fault is detected; and / orwherein the detection of an occurrence of the first short duration fault comprises that the controllers are periodically monitored, one of the controllers as inactive and subsequently the one of the controllers is identified as active; and / or wherein locating the intermittent fault in the CAN based on the first and second sets of faults comprises: determining a fault model that includes multiple faults and corresponding observed inactive controllers for the CAN comprises determining an inactive one of the controllers that is common to the first and second sets of errors; and locating the intermittent fault in the CAN based on the inactive one of the controllers and the fault model.

Description

TECHNICAL AREA

This invention relates to a method of monitoring a controller area network according to the preamble of claim 1, as it appears essentially from FIG DE 100 29 642 B4 is known.

BACKGROUND

Vehicle systems include multiple subsystems including, for example, the engine, transmission, drive feel / handling, braking, HVAC, and occupant protection. Multiple controllers can be used to monitor and control the operation of the subsystems. The controllers can be configured to communicate over a Controller Area Network (CAN) to coordinate the operation of the vehicle in response to operator commands, vehicle operating states, and external conditions. An error can occur in one of the controllers that affects communications over a CAN bus.

A network topology, such as a CAN, relates to an arrangement of elements. Known CAN systems use a bus topology for the communication link between all controllers, which can include a line topology, a star topology or a combination of star and line topology. Known CAN systems for high speed use a line topology, whereas known CAN systems for low speed use a combination of star and line topology. Known CAN systems use separate power and ground topologies for the power and ground lines to all controllers. Known controllers communicate with one another via messages that are sent on the CAN bus in different periods. A physical topology describes the arrangement or division of physical elements that comprise links and nodes. A logical topology describes the flow of data messages or performance in a network between nodes using links.

Known systems detect errors on a message reception controller, the error detection for the message being achieved using signal control and signal timeout monitoring at an interaction layer of the controller. The errors can be reported as loss of communications. Such detection systems are generally not able to identify a root cause of a fault and are not able to differentiate between transient and intermittent faults. A known detection system requires separate monitoring hardware and dimensional details of a physical topology of a network in order to effectively monitor and detect faults in the network.

SUMMARY

A controller area network (CAN) has several CAN elements that include a communication bus and several controllers. According to the invention, a method for monitoring the CAN is presented which has the features of claim 1.

Figure list

• 1 ein Fahrzeug, das ein Controller Area Network (CAN) mit einem CAN-Bus und mehrere Knoten, z.B. Controller, umfasst, gemäß der Offenbarung zeigt;
• 2 ein integriertes Controller Area Network, das analog zu dem CAN von 1 ist und einen CAN-Bus mit Kabeln, mehrere Knoten, z.B. Controller, und eine Datenverbindungssteuerung umfasst, gemäß der Offenbarung zeigt;
• 3 schematisch eine beispielhafte CAN-Überwachungsroutine zum Detektieren und Isolieren eines intermittierenden Fehlers in einem CAN gemäß der Offenbarung zeigt;
• 4 eine Controller-Aktiv-Kontrollroutine zum Überwachen des Controllerstatus einschließlich eines Detektierens, ob einer der mit dem CAN-Bus verbundenen Controller inaktiv ist, gemäß der Offenbarung zeigt;
• 5, die die 5-1 und 5-2 umfasst, eine Zeitachse, die einen Controllerstatus für mehrere CAN-Elemente, die mehrere Controller umfassen, in Relation zur Zeit angibt, gemäß der Offenbarung zeigt; und
• 6 ein beispielhaftes CAN, das Controller, einen Überwachungscontroller, eine Leistungsversorgung, eine Batteriesterneinrichtung und eine Masse, die jeweils über eine Verbindung verbunden sind, umfasst, gemäß der Offenbarung zeigt.

One or more embodiments are described below by way of example, reference being made to the accompanying drawings, in which:

• 1 shows a vehicle comprising a controller area network (CAN) with a CAN bus and multiple nodes, eg controllers, according to the disclosure;
• 2 an integrated controller area network, which is analogous to the CAN from 1 Figure 3 shows a CAN bus with cables, multiple nodes, e.g. controllers, and a data link controller in accordance with the disclosure;
• 3 schematically depicts an exemplary CAN monitor routine for detecting and isolating an intermittent fault in a CAN in accordance with the disclosure;
• 4th Figure 12 shows a controller active control routine for monitoring controller status including detecting whether any of the controllers connected to the CAN bus is inactive, in accordance with the disclosure;
• 5 who the 5-1 and 5-2 comprises a timeline showing controller status for multiple CAN elements comprising multiple controllers in relation to time, according to the disclosure; and
• 6th An exemplary CAN including controllers, a supervisory controller, a power supply, a battery star device, and a ground, each connected via a link, according to the disclosure.

DETAILED DESCRIPTION

Referring now to the drawings, the representations being for the purpose of explaining certain exemplary embodiments, FIG 1 schematically a vehicle 8th , which is a Controller Area Network (CAN) 50 with a CAN bus 15th and multiple nodes, ie controllers 10 , 20th , 30th and 40 , includes. The term "node" refers to any active electronic device that has signals on the CAN bus 15th connected and information about the CAN bus 15th can send, receive or forward. Each of the controllers 10 , 20th , 30th and 40 is via signals with the CAN bus 15th connected and electrically connected to a power grid 60 and a mass network 70 connected. Each of the controllers 10 , 20th , 30th and 40 includes an electronic controller or other on-vehicle device configured to operate a subsystem of the vehicle 8th to monitor or control and via the CAN bus 15th to communicate. In one embodiment, one of the controllers is, for example, controllers 40 , designed to use the CAN 50 and the CAN bus 15th monitor, and it may be referred to herein as a CAN controller. The illustrated embodiment of the CAN 50 is a non-limiting example of a CAN that can be used with any of a variety of system configurations.

The CAN bus 15th comprises several communication links that have a first communication link 51 between the controllers 10 and 20th , a second communication link 53 between the controllers 20th and 30th and a third communication link 55 between the controllers 30th and 40 include. The power network 60 includes a power supply 62 , e.g. a battery that is electrically connected to a first power bus 64 and a second power bus 66 connected to the controllers 10 , 20th , 30th and 40 provide electrical power via power connections. As shown is the power supply 62 with the first performance bus 64 and the second power bus 66 connected via power connections that are arranged in a serial configuration, wherein a power connection 69 the first and second power buses 64 and 66 connects. The first performance bus 64 is with the controllers 10 and 20th connected via power connections which are arranged in a star configuration, wherein power connection 61 the first performance bus 64 and the controller 10 connects and power connection 63 the first performance bus 64 with the controller 20th connects. The second performance bus 66 is with the controllers 30th and 40 connected via power connections which are arranged in a star configuration, wherein power connection 65 the second power bus 66 and the controller 30th connects and power connection 67 the second power bus 66 with the controller 40 connects. The mass network 70 includes a vehicle mass 72 with a first mass bus 74 and a second ground bus 76 connected to the controllers 10 , 20th , 30th and 40 provide an electrical ground via ground connections. As shown is the vehicle mass 72 via ground connections, which are arranged in a serial configuration, with the first ground bus 74 and the second ground bus 76 connected, with ground connection 79 the first and second ground bus 74 and 76 connects. The first mass bus 74 is with the controllers 10 and 20th connected via ground connections arranged in a star configuration, with ground connection 71 the first mass bus 74 and the controller 10 connects and ground connection 73 the first mass bus 74 with the controller 20th connects. The second ground bus 76 is with the controllers 30th and 40 connected via ground connections arranged in a star configuration, with ground connection 75 the second ground bus 76 and the controller 30th connects and ground connection 77 the second ground bus 76 with the controller 40 connects. Other topologies for distributing communications, power, and ground for the controllers 10 , 20th , 30th and 40 and the CAN bus 15th can be used with a similar effect.

Control module, module, controller, controller, control unit, processor and similar terms include one or various combinations of one or more application-specific integrated circuits (ASIC), electronic circuit (s), central processing unit (s) (preferably microprocessor (s)) and an assigned memory (read-only memory, programmable read-only memory, random access memory, hard disk, etc.), which execute one or more software or firmware programs or routines, Combinational logic circuit (s), input / output circuit (s) and devices, suitable signal conditioning and buffering circuitry, and other components to provide the functionality described. Software, firmware, programs, instructions, routines, code, algorithms, and similar terms encompass any instruction set that includes calibrations and look-up tables. The control module has a set of control routines that are executed to provide the desired functions. Routines are executed, for example, by a central processing unit and are used to monitor inputs from detection devices and other networked control modules and to execute control and diagnostic routines in order to control the operation of actuators. Routines can be executed at regular intervals, such as every 100 microseconds, 3.125, 6.25, 12.5, 25, and 100 milliseconds, during continued machine and vehicle operation. Alternatively, routines can be executed in response to the occurrence of an event.

Each of the controllers 10 , 20th , 30th and 40 transmits and receives messages via the CAN 50 via the CAN bus 15th , with message transfer rates for different ones of the controllers with different periods. A CAN message has a known, predetermined format that includes, for example, a frame start (SOF from start of frame), an identifier (11-bit identifier), a single remote transmission request (RTR), a dominant single one Identifier extension (IDE from identifier extension), a reserve bit (r0), a data length code (DLC from data length code) with 4 bits, up to 64 bits of data (DATA), a cyclic redundancy check (CDC from cyclic redundancy check) with 16 bits, an acknowledgment (ACK of acknowledgment) with 2 bits, a frame end (EOF of end-of-frame) with 7 bits and an interframe space (IFS of interframe space) with 3 bits. A CAN message can be damaged, known faults including fill faults, shape faults, ACK faults, bit 1 faults, bit 0 faults and CRC faults. The faults are used to generate a fault warning status comprising a fault active status or a fault passive status or a bus off fault status. The fault active status, the fault passive status and the bus off fault status are assigned on the basis of an increasing number of detected bus fault frames, ie an increasing bus fault count. Known CAN bus protocols include the provision of network-wide data consistency, which can lead to a globalization of local disturbances. This enables a faulty controller that is not standing still to send a message to the CAN bus 15th damage that came from another of the controllers. A faulty controller that is not idle is referred to herein as an active controller with a fault. If one of the controllers is assigned the bus-off fault status, it is prohibited from communicating on the CAN bus for a period of time. This includes prohibiting the affected controller from receiving messages and transmitting messages until a reset event occurs, which can occur after a period of time when the controller is inactive. Thus, an active controller with a fault, if it is assigned the bus-off fault condition, is forbidden from communicating on the CAN bus for a period of time, and it cannot damage any other messages on the CAN bus during the period of time if it is inactive.

2 shows schematically an integrated controller area network 250 that related to 1 shown CAN 50 is similar and a CAN bus 215 with two wires that connect the CAN + cables 201 and CAN 203 includes, and several nodes, e.g. the controller 210 , 220 , 230 and 240 , includes. As shown is the controller 240 a supervisory controller. A line break fault on one of the cables, e.g. a line break fault on CAN + 201 between controller 210 and 220 , interrupts the bus communications from the controller 210 to the controller 220 , 230 and 240 . This can cause the controllers 220 , 230 and 240 put in a bus-off state and detected as an inactive node.

A CAN fault is a malfunction that results in a lost or damaged message on the CAN bus, thereby interrupting communications between controllers in the CAN. A CAN error can be caused by an interrupted communication connection, an interrupted power connection, an interrupted ground connection, a communication connection-power or ground short-circuit, a power-ground short-circuit or a fault in a controller. An error can be site-specific. A communication error can be the result of an error in one of the controllers, an error in one of the communication connections of the CAN bus, an error in one of the power connections of the power network or an error in one of the ground connections of the ground network. Topology diagrams can be developed that include a communication topology, a power topology, and a ground topology. A reachability analysis is carried out for each of the topology diagrams with remote connection interruption. One embodiment of a reachability analysis of a topology diagram is described with respect to FIG 6th described.

A short duration CAN error is defined as any short duration malfunction that causes a temporary error, resulting in a lost or damaged message on the CAN bus. The short duration malfunction lasts for a short period of time, for example less than a second, and can be self correcting. An intermittent CAN error is defined as a brief CAN error that occurs at least twice within a predefined time window, which in one embodiment is ten Seconds. A transient CAN error is defined as a short-term error that occurs only once within the predefined time window.

Detecting and locating an intermittent CAN fault in one embodiment of a controller area network (CAN) includes periodically identifying each of the controllers as either active or inactive by monitoring communications and messaging on the CAN bus. Several short CAN errors can be detected during ongoing operation, which means that several short CAN errors occur within the predefined time window, e.g. within a time window of ten seconds. For each of the short-term CAN errors in the predefined time window, a controller error set is preferably identified, which includes one or more inactive controllers. If more than one brief CAN error occurs in the predefined time window, the brief CAN error is considered to be intermittent. The controller error sets, which include the identified inactive controllers for each of the short-term CAN errors, are subjected to filtering, which may include error set integration, error set overlap analysis or other suitable analytical technique that identifies one or more inactive controllers that all controller error sets have in common are. The identified one or more of the inactive controllers, which is / are common to all controller fault sets, can be used in the reachability analysis of a communication topology diagram in order to detect, locate and isolate the intermittent fault in the CAN.

3 shows schematically an exemplary CAN monitoring routine 300 for detecting and isolating an intermittent communication error in a CAN. Table 1 becomes routine as a legend 300 of 3 where the numerically labeled boxes and corresponding functions are performed as follows. Table 1 BOX BOX CONTENTS 302 begin 304 Set int_timer = int_timer - 1 if not zero. Set busoff timer = busoff timer - 1 if not zero 306 Call the controller active control routine 308 Are any of the controllers inactive, ie is Inactive [i] = 1 for any controller [i]? 310 Is fflag = 1? 312 Set error flag: fflag = 1 Reset busoff timer Reset active controller to unknown status Save current error information 314 Update past error information. Update current error information 320 Is fflag = 1? 322 Set fflag = 0 324 Is int_timer = 0? 326 Reset error count value (fcount = 0) Reset integrated error information 328 Is busoff_timer = 0? AND Is int inactive [i] [M] = 1 for a controllerfi]? 330 Update error count. Reset inter-arrival timer. Perform data filtering and update built-in error information 332 Is fcount = COUNT_TO_REPORT_FAULT? 334 Reports built-in error information for diagnosis 340 end

• T_d, was das Ausführungsintervall der CAN-Überwachungsroutine 300 ist und ein kalibrierbarer Wert mit einem Voreinstellungswert von 50 ms ist;
• N, was die Gesamtmenge an Controllern in dem CAN ist;
• BUSOFF_RECOVERY_TIME, was eine kalibrierbare Menge an Ausführungszyklen der CAN-Überwachungsroutine 300 ist, die eine verstrichene Zeit für eine Wiederherstellung von Kommunikationen angibt;
• INTER_ARRIVAL_TIME, was eine kalibrierbare Schwellenwertmenge von Zyklen der CAN-Überwachungsroutine 300 ist, die eine verstrichene Zeit zwischen zwei kurz dauernden Fehlern angibt. Wenn die verstrichene Zeit zwischen den beiden kurz dauernden Fehlern kleiner als INTER_ARRIVAL_TIME ist, werden die kurz dauernden Fehler als intermittierende Fehler betrachtet. Wenn die verstrichene Zeit zwischen den beiden kurz dauernden Fehlern größer als INTER_ARRIVAL_TIME ist, werden die kurz dauernden Fehler als transiente Fehler betrachtet, die nicht berichtet werden. Bei einer Ausführungsform wird INTER_ARRIVAL_TIME auf 10 Sekunden gesetzt; und COUNT_TO_REPORT_FAULT, was eine kalibrierbare minimale Schwellenwertmenge kurz dauernder CAN-Fehler ist, die erforderlich ist, um das Vorkommnis eines intermittierenden Fehlers zu berichten.

The execution of the CAN monitoring routine 300 Associated parameters that can be calibrated include the following:

• T _d , which is the execution interval of the CAN monitoring routine 300 and is a calibratable value with a default value of 50 ms;
• N, which is the total amount of controllers in the CAN;
• BUSOFF_RECOVERY_TIME, which is a calibratable number of execution cycles of the CAN monitoring routine 300 is that indicates an elapsed time for restoration of communications;
• INTER_ARRIVAL_TIME, which is a calibratable threshold amount of cycles of the CAN monitoring routine 300 which indicates an elapsed time between two short-term errors. If the elapsed time between the two short-term errors is less than INTER_ARRIVAL_TIME, the short-term errors are regarded as intermittent errors. If the elapsed time between the two brief errors is greater than INTER_ARRIVAL_TIME, the brief errors are considered transient errors and are not reported. In one embodiment, INTER_ARRIVAL_TIME is set to 10 seconds; and COUNT_TO_REPORT_FAULT, which is a calibratable minimum threshold amount of short duration CAN errors required to report the occurrence of an intermittent error.

• fflag, was ein Flag ist, das angibt, dass ein Fehler auftritt;
• int_timer, was ein Timer ist, der die verstrichene Zeit zwischen Vorkommnissen von zwei der kurz dauernden CAN-Fehler misst, d.h. das vordefinierte Zeitfenster;
• busoff_timer, was ein Bus-Aus-Wiederherstellungs-Timer ist;
• fcount, was eine Menge kurz dauernder CAN-Fehler ist;
• int_inactive[i][j], was den Status eines intermittierenden Fehlers für jeden Controller [i] und für M Zyklen angibt, wobei i = 1, ..., N, Menge an Controllern, und j = 1, ..., M, wobei M = BUSOFF_RECOVERY_TIME-Zyklen + 1; und
• finactive[i] ist eine integrierte Fehlerinformation für jeden Controller nach dem Ausführen einer Datenfilterung von mehreren kurz dauernden CAN-Fehlern und i = 1, ..., N, Menge an Controllern.

The variables that the execution of the CAN monitoring routine 300 include the following:

• fflag, which is a flag indicating that an error is occurring;
• int_timer, which is a timer that measures the elapsed time between occurrences of two of the brief CAN errors, ie the predefined time window;
• busoff_timer, which is a bus-out recovery timer;
• fcount, which is a bunch of short-lived CAN errors;
• int_inactive [i] [j], which indicates the status of an intermittent failure for each controller [i] and for M cycles, where i = 1, ..., N, amount of controllers, and j = 1, ..., M, where M = BUSOFF_RECOVERY_TIME cycles + 1; and
• finactive [i] is an integrated error information for each controller after a data filtering of several short-term CAN errors and i = 1, ..., N, number of controllers.

When switching on, the variables are initialized as follows: fflag = 0, int_timer = 0; busoff_timer = 0; fcount = 0, finactive [i] = -1 for i = 1, ..., N, int_inactive [i] [j] = -1 for i = 1, ..., N and j = 1, ... , M, where -1 indicates an unknown status.

When starting the execution of the current iteration ( 302 ) several operations are performed including decrementing the timer (int_timer), which measures the elapsed time between the occurrences of two errors, and decrementing the timer (busoff_timer), which measures the bus-off recovery time ( 304 ).

A controller active control routine is called to receive controller active reports for the CAN controllers ( 306 ). One embodiment of a controller active control routine is herein with respect to FIG 4th described.

The controller active reports are evaluated ( 308 ), and if none of the controllers is inactive (Inactive [i] = 1?) ( 308 ) (0), the error flag is evaluated to determine whether it was set (fflag = 1?) ( 320 ). If the error flag was not set ( 320 ) (0), this iteration ends ( 340 ). If the error flag has been set ( 320 ) (1), the error flag is reset (fflag = 0) ( 322 ). The timer, which measures the elapsed time between two short-term errors (int_timer), is evaluated ( 324 ) to see if it has expired, indicating that no intermittent error has occurred. When the timer that measures the time elapsed between two brief errors (int_timer) has expired ( 324 ) (1), the error count is reset (fcount = 0) and the integrated error information is reset to indicate that the error status of all controllers is unknown (finactive [i] = -1 for i = 1, ..., N) ( 326 ). If the timer that measures the time elapsed between two brief errors (int_timer) has not expired ( 324 ) (0), the actions are from step 326 skipped.

The bus-off recovery timer and the status of an intermittent error are evaluated for each controller [i] for M cycles ( 328 ). If either the bus-off recovery timer has not expired (busoff_timer ≠ 0) or the status of an intermittent error for all controllers for the M-th cycle fails to indicate an error in any of the controllers (int_inactive [i] [M] = 0) ( 328 ) (0), this iteration ends ( 340 ). If the bus-off recovery timer has expired (busoff_timer = 0) and the status of an intermittent error indicates an error for one or more of the controllers for the M-th cycle (int_inactive [i] [M] = 1) ( 328 ) (1), operation continues with the following actions which include updating the error count value (fcount = fcount + 1), resetting the inter-arrival timer (int_timer = INTER_ARRIVAL_TIME) and performing data filtering and any built-in error information is updated ( 330 ).

• für i = 1 bis N,
  • wenn int_inactive[i][M]=0
  • dann finactive[i]=0,
  • ansonsten wenn int_inactive[i][M]=1 und finactive[i]= -1
  • dann finactive[i]=1.

Performing data filtering and updating the built-in fault information for each controller from multiple intermittent faults includes the following:

• for i = 1 to N,
  • if int_inactive [i] [M] = 0
  • then finactive [i] = 0,
  • otherwise if int_inactive [i] [M] = 1 and finactive [i] = -1
  • then finactive [i] = 1.

The error count value (fcount) is evaluated, and if it is equal to a minimum error count value (fcount = COUNT_TO_REPORT_FAULT) ( 332 ) (1), the system reports the integrated error information for a diagnosis using the topology data (reports (finactive [i], i = 1, ..., N) ( 334 ), and this iteration ends ( 340 ). If the error count is less than a minimum error count, i.e. less than COUNT_TO_REPORT_FAULT ( 332 ) (0), this iteration ends without further action ( 340 ).

If any one or more of the controllers is or are inactive (Inactive [i] = 1) ( 308 ) (1), the error flag is evaluated to determine whether it has been set (fflag = 1?) ( 310 ). If the error flag was not set ( 310 ) (0), if the error flag is set (fflag = 1), if the bus off timer is reset (busoff_timer = BUSOFF_RECOVERY_TIME), all active controllers are reset to the unknown status (for i = 1 to N, inactive [ i] = -1, if inactive [i] = 0), and the error information of the current cycle is saved (for i = 1 to N, if inactive [i] = 1, then int_inactive [i] [1] = 1, otherwise int_inactive [i] [1] = -1) ( 312 ). This iteration ends without further action ( 340 ).

If the error flag has been set ( 310 ) (1), the first error information from the past is updated (for i = 1 to N, j = M to 2, int_inactive [i] [j] = int_inactive [i] [j-1]) and the current error information is saved (if inactive [i] = 0, then int_inactive [i] [1] = 0, otherwise, if inactive [i] = 1 and int_inactive [i] [1] = -1, then int_inactive [i] [1] = 1) ( 314 ). The current error information and the error information of the past are error records which indicate a current inactive controller / current inactive controller or an inactive controller / inactive controller of the past. This iteration ends without further action ( 340 ).

4th shows schematically the controller active control routine 400 for monitoring the controller status, which includes detecting whether any of the controllers connected to the CAN bus is inactive. The controller active control routine 400 is executed to obtain controller active reports based on monitoring communications originating from the controllers in the CAN. The controller active control routine 400 is periodically carried out by the CAN monitoring routine 300 called. Table 2 is used as a legend for the controller active control routine 400 of 4th where the numerically labeled boxes and corresponding functions are performed as follows. Table 2 BOX BOX CONTENTS 402 Initialize terms 404 Set T [i] = T [i] - 1 if T [i]> 0 for each controller [i] 406 Query controller - was a new message received from controller [i]? 408 Set Inactive [i] = 0 Reset T [i] = Th [i] 410 Is T [i] = 0 for some controller [i]? 412 Set inactive [i] = 1 for all controllers [i] 415 Return inactive [i] = 1 for all controllers [i]

• i bezeichnet einen spezifischen Controller[i], wobei i = 1, ...., N,
• N ist die Gesamtanzahl an Controllern in dem CAN; und
• Th[i] ist der Zeitüberschreitungswert für eine Aktiv-Kontrolle der Controller[i], der durch die Anzahl von Zyklen der CAN-Überwachungsroutine 300 gemessen wird und kalibrierbar ist.

The parameters include the following:

• i denotes a specific controller [i], where i = 1, ...., N,
• N is the total number of controllers in the CAN; and
• Th [i] is the timeout value for active control of the controller [i], which is determined by the number of cycles of the CAN monitoring routine 300 is measured and can be calibrated.

• T[i] ist ein Timer für die Aktiv-Kontrolle von Controller[i]; und
• inactive[i] gibt einen interaktiven Status von Controller[i] an, wo bei i=1, ..., N.

The variables include the following:

• T [i] is a timer for the active control of controller [i]; and
• inactive [i] indicates an interactive status of controller [i], where i = 1, ..., N.

When executing the controller active control routine for the first time 400 ( 402 ) in each ignition cycle a timeout value Ti for the active control of the controller according to T [i] = Th [i], inactive [i] = -1, where -1 represents an unknown status and i = 1, ..., N, initialized. Thus, at the beginning of the first execution of this routine in each ignition cycle, the controllers are not designated as being in the active state or in the inactive state.

The timeout value T [i] is decremented by 1, i.e. T [i] = T [i] -1 if T [i] is greater than zero for one of the controllers ( 404 ), and the system monitors to see if any new message has been received from any of the controllers ( 406 ). If this is the case ( 406 ) (1), the inactive flag inactive [i] for the specific controller [i] from which a message was received is reset (= 0) and the timeout value T [i] is reinitialized with Th [i] ( 408 ). Furthermore, or if no new message has been received from any of the controllers ( 406 ) (0), the timeout value T [i] is evaluated to determine whether it has reached a value of zero for any of the controllers ( 410 ), and if so ( 410 ) (1), the inactive flag Inactive [i] is set for each specific controller from which no message was received (= 1) ( 412 ). If not ( 410 ) (0), this iteration ends, passing to the identification monitoring routine 300 The returned results indicate which of the specific controllers connected to the CAN bus, if there is one, is inactive (inactive [i] for all controllers [i]) ( 415 ).

5 that from the 5-1 and 5-2 exists, shows schematically a time axis 500 that for several CAN elements that control the controller 502 , 504 and 506 indicate the controller status, ie active or inactive, in relation to the time. The timeline 500 shows the operation of the CAN monitoring routine 300 what the controller status is active (1) and inactive (0) for each of the controllers 502 , 504 and 506 includes. The operation of a supervisory controller is not shown. The controllers 502 , 504 and 506 are active at the beginning of a first fault detection window (1), as it was at point in time 512 is shown. At the time 513 a first error occurs. The location of the first error is unknown to a monitoring controller, but for explanatory purposes it is shown as an interrupted line on the positive line (CAN +) between the controllers 502 and 504 shown. At the time 514 becomes controller 504 assigned to the out-of-bus fault state due to the fault caused by the first fault, and it goes into a out-of-bus recovery mode and changes to the inactive (0) status. The first fault detection window ends at this point in time 516 , and both controllers 502 and 504 are inactive (0) due to the malfunction caused by the error. Controller 506 remains active (1). During a second fault detection window, the broken line on the positive line (+) between the controller 502 and 504 at the time 517 reconnected, thereby ending the occurrence of the first failure. The second fault detection window ends at this point in time 518 , where the controller 502 becomes active at this point in time (1). Due to the operation of the bus-out recovery mode, the controller remains 504 inactive (0). The controller 506 remains unchanged and active (1).

The following error detection windows take place between the points in time 518 and 520 without changing the status for the controllers 502 , 504 and 506 instead of. At the time 522 the bus-out recovery time expires, and the controller 504 becomes active (1), which indicates the existence of a first short-term error. Between the points in time 522 and 524 there is an interrogation delay that occurs when the current error detection window ends. The supervisory controller identifies the inactive controllers associated with the first short-term fault by identifying the controllers that are inactive at the end of a fault detection window that occurs at the beginning of the bus-out recovery time, taking into account the polling delay. Thus, the inactive controllers associated with the first short-term error are the controllers that at the time 516 are inactive as shown.

At the time 524 are the controllers 502 , 504 and 506 all active and stay over time 526 active.

At the time 527 a second error occurs. A difference between point in time 527 and timing 513 returns an elapsed time between two short-term errors (int_timer), which is evaluated and indicates the occurrence of an intermittent error. The location of the error is unknown to a monitoring controller, but for explanatory purposes it again includes an interrupted line on the positive line (CAN +) between the controllers 502 and 504 . At the time 528 becomes controller 506 associated with the out-of-bus fault condition, it changes to the inactive (0) state and goes into out-of-bus recovery mode due to the fault caused by the fault. This error detection window ends at this point in time 530 , and both controllers 502 and 506 are inactive (0) due to the malfunction caused by the error. The controller 504 remains active (1). During a subsequent error detection window, the interrupted line becomes the positive line (CAN +) between the controllers 502 and 504 at the time 531 reconnected, thereby ending the occurrence of the fault. The subsequent error detection window ends at this point in time 532 , where the controller 502 becomes active at this point in time (1). Controller 506 remains inactive (0) due to the bus-out recovery mode operation. Controller 504 remains unchanged and active (1).

The following error detection windows take place between the points in time 532 and 534 without changing the status for the controllers 502 , 504 and 506 instead of. At the time 536 the bus-out recovery time is running out, whatever controller 506 enables the bus-off fault status to be exited and to become active (1), which indicates the presence of a second short-term error. Between the points in time 536 and 538 there is an interrogation delay which occurs when the current fault detection window ends. The supervisory controller identifies the inactive controllers associated with the second short-term fault by identifying the controllers that are inactive at the end of a fault detection window that occurs at the beginning of the bus-out recovery time, taking the polling delay into account. Thus, the inactive controllers associated with the second short-term error are the controllers at the point in time 530 are inactive as shown. At the time 538 are the controllers 502 , 504 and 506 all active and remain active. The CAN monitoring routine 300 gets accurate error information by taking the bus out recovery time and polling delay into account to identify the first set of errors affecting the controllers 502 and 504 includes the time of the first intermittent fault 516 and to identify a second set of errors that the controllers 502 and 506 includes the second intermittent fault at time 530 are associated. The subsequent filtering and integration of the first and second sets of errors identifies controllers 502 as the inactive controller that is common to both the first and second sets of faults, which can be used for diagnosis using topology data and reachability analysis to identify the location of the intermittent fault.

6th shows a network topology for an exemplary CAN 600 who have favourited the controller 602 , 604 and 606 , a surveillance controller 608 , a power supply 610 , a battery star device 612 and a crowd 614 which are each connected via a communication link as shown. The supervisory controller 608 observes symptoms indicating different sets of errors, each set of errors having a corresponding error signature that includes a set of inactive controllers. The supervisory controller 608 may include any or all of the controllers on the communication bus, that is, all of the controllers may be configured to perform fault diagnosis, since any message on the CAN bus can be observed at any of and all of the controller nodes.

A fault model is generated for the network topology that includes multiple symptoms that are observed by a monitoring ^{controller for each of several network or CAN faults, and a corresponding fault signature vector} _{V f} inactive that includes a set of observed associated inactive controllers. An exemplary fault model that corresponds to the network topology of 6th Associated with, includes the following in relation to Table 3, the network topology for the CAN 600 the controllers 602 [1], 604 [2] and 606 [3], the supervisory controller 608 [0], the power supply 610 [4], the battery star device 612 [5] and the crowd 614 [6] includes. The error model is created using an accessibility analysis of the network topology deriving the symptom and monitoring communications to determine which of the controllers is inactive on that symptom. Table 3 Set of errors symptom Contents of error ^{nature vector Vf inactive} f1 Broken connection [1] - [2] [1] Broken connection [1] - [5] Broken connection [1] - [6] [1] error f2 Broken connection [2] - [4] [2] Broken connection [2] - [6] [2] error f3 Broken connection [3] - [5] [3] Broken connection [3] - [6] [3] error f4 Broken connection [2] - [3] [1], [2] f5 Broken connection [4] - [5] [1], [3] f6 Broken connection [1] - [2] [1], [2], [3] CAN bus short circuit

A first set of errors f1 can be a symptom of a broken connection between controllers 602 and battery star device 612 or controller 602 and mass 614 or controller 602 and controller 604 and a bug with controller 602 include, with a corresponding fault ^{signature vector} _{V f} inactive controller 602 as inactive. A second set of errors f2 can be a symptom of a broken connection between controllers 604 and battery 610 or controller 604 and mass 614 and a bug with controller 604 include, with a corresponding fault ^{signature vector} _{V f} inactive controller 604 as inactive. A third set of errors f3 can be a symptom of an interrupted connection between controllers 606 and battery star device 612 or controller 606 and mass 614 and a bug with controller 606 include, with a corresponding fault ^{signature vector} _{V f} inactive controller 606 as inactive. A fourth set of errors f4 can be a symptom of a broken connection between controllers 604 and controller 606 include, with a corresponding fault ^{signature vector} _{V f} inactive the controller 602 and 604 as inactive. A fifth set of errors f5 can be a symptom of a broken connection between the battery 610 and battery star device 612 include, with a corresponding fault ^{signature vector} _{V f} inactive the controller 602 and 606 as inactive. A sixth error record f6 can be a symptom of an interrupted connection between the monitoring controller 608 and controller 606 include, with a corresponding fault ^{signature vector} _{V f} inactive the controller 602 , 604 and 606 as inactive. Another fault ^{signature vector} _{V f} inactive can be developed according to a specific architecture of a CAN system, using an accessibility analysis of a topology diagram of the CAN.

A CAN monitoring routine can isolate a fault by generating a system model that includes one or more controllers and / or a monitoring controller. Each of the controllers transmits a set of messages that can have different periods or repetition rates. Topology diagrams such as in relation to 6th The topologies shown include G _bus , G _bat and G _{gnd associated} with the communication bus, the power bus and the ground bus, respectively. A fault set F may include any controller node fault, bus link break fault, power link break fault, ground link break fault, and other faults for the topology diagrams. A pre-operational application generates a fault ^{signature vector} _{V f} inactive, which consists of a set of inactive controllers associated with each fault f, for each fault f in fault set F. The fault ^{signature vector} _{V f} inactive is used to identify a fault in one of the Isolate controllers, bus connections, power connections, ground connections, etc.

Claims (6)

A method of monitoring a controller area network (CAN) comprising multiple CAN elements comprising a communication bus and multiple controllers, the method comprising: occurrences of a first short CAN fault and a second short CAN fault within a predefined time window are detected; a first set of errors is identified which includes at least one inactive controller associated with the first short-term CAN error; characterized in that a second set of errors is identified which comprises at least one inactive controller associated with the second brief CAN error; and locating an intermittent fault in the CAN based on the first and second sets of faults; wherein detecting occurrences of the first short CAN error and the second short CAN error within the predefined time window comprises that: the first short CAN error is detected; and the second brief CAN error that occurs after the detection of the first brief CAN error is detected; and / or wherein detecting an occurrence of the first short-term error comprises that the controllers are periodically monitored, one of the controllers is identified as inactive and subsequently the one of the controllers is identified as active; and / or wherein locating the intermittent fault in the CAN based on the first and second sets of faults comprises: determining a fault model comprising a plurality of faults and corresponding observed inactive controllers for the CAN; determining an inactive one of the controllers that is common to the first and second sets of errors; and locating the intermittent fault in the CAN based on the inactive one of the controllers and the fault model. Procedure according to Claim 1 , wherein the first and second short duration CAN errors comprise a malfunction of a short duration causing a lost or corrupted message on the communication bus. Procedure according to Claim 1 wherein detecting occurrences of the first short-term fault and the second short-term fault within the predefined time window comprises periodically identifying each of the controllers as either active or inactive. Procedure according to Claim 1 wherein identifying one of the controllers as inactive and subsequently identifying the one of the controllers as active comprises identifying the one of the controllers as active less than one second after the one of the controllers is identified as inactive. Procedure according to Claim 1 wherein the determination of the fault model comprising the plurality of faults and the corresponding observed inactive controllers for the CAN comprises that an availability analysis of a communication topology of the CAN is carried out. Procedure according to Claim 1 wherein locating the intermittent fault in the CAN based on the inactive one of the controllers and the fault model comprises locating a controller node fault or a CAN bus connection disconnection fault or a power connection disconnection fault or a ground connection disruption fault or a power-to-ground short circuit fault.

Images